December 2019 - mkgmap-dev - The mkgmap lists

documentation improvement patch
by Mike Baggaley 30 Jan '20

30 Jan '20

Hi Gerd, I have attached a patch to improve the documentation of the command line. I did it some time ago and had forgotten about it, but the discussion on whether to change default options prompted me to come back to it. The change is purely to the documentation, no code changes. Please review and if it meets with your approval, commit. Thanks, Mike

6 28

Suggestions for roadNameConfig.txt
by Alexandre Folle de Menezes 23 Jan '20

23 Jan '20

Hi, I have some suggestions to improve Portuguese handling on roadNameConfig.txt: # portugese prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda", "Beco", "Estrada", "Rodovia" prefix2:pt = "da ", "do ", "de ", "das ", "dos ", "d'" # Section 2 lang:AGO = pt lang:BRA = pt lang:GNB = pt lang:MOZ = pt Best regards, Alexandre

3 5

TYP files and character encoding
by Ticker Berkin 19 Jan '20

19 Jan '20

Hi A couple of problems with typ-files and unicode. With 'Codepage=65001' the final contents of the labels in mapnik.typ that is included with the composite map is unicode, but if the map is codepage 1252, the unicode characters with the top bit set are simply displayed as if in 1252. Removing the codepage statement from mapnik.txt and making fixes elsewhere to ensure that the file is read correctly as utf-8 and then generating a map with --code-page=1252, it gives the error: SEVE: uk.me.parabola.imgfmt.MapFailedException ../svn/trunk/resources/typ-files/mapnik.txt: (thrown in TypCompiler.makeMap()) TYP file cannot be written in code page 1252 Changing the exception handling in imgfmt/app/typ/TypElement.java, so that makeLabelBlock() reads as ... CharBuffer cb = CharBuffer.wrap(tl.getText()); try { ByteBuffer buffer = encoder.encode(cb); out.put((byte) tl.getLang()); out.put(buffer); out.put((byte) 0); } catch (CharacterCodingException ignore) { // ignore.printStackTrace(); String name = encoder.charset().name(); System.out.println("Cannot represent String=" + tl.getLang() + "," + tl.getText() + " in CodePage=" + name); // throw newTypLabelException(name); } ... It gives output like: Cannot represent String=21,Gara|e in CodePage=windows-1252 Cannot represent String=21,Obszar przemysBowy in CodePage=windows-1252 Cannot represent String=21,ZieleD in CodePage=windows-1252 Cannot represent String=21,Zaro[la in CodePage=windows-1252 Cannot represent String=21,MokradBa in CodePage=windows-1252 Cannot represent String=21,Droga wojew\363dzka (B^Ecznik) in CodePage=windows-1252 Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in CodePage=windows-1252 Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in CodePage=windows-1252 Cannot represent String=21,Zcie|ka rowerowa in CodePage=windows-1252 Cannot represent String=21,Wybrze|e in CodePage=windows-1252 Cannot represent String=21,Zcie|ka in CodePage=windows-1252 Cannot represent String=21,StrumieD in CodePage=windows-1252 Cannot represent String=21,Granica paDstwa in CodePage=windows-1252 Cannot represent String=21,Rzeka, KanaB in CodePage=windows-1252 Cannot represent String=21,StrumieD in CodePage=windows-1252 Cannot represent String=21,Ruroci^Eg in CodePage=windows-1252 Cannot represent String=21,Kabel wysokiego napi^Ycia in CodePage=windows-1252 Cannot represent String=21,Tor wy[cigowy in CodePage=windows-1252 Cannot represent String=21,Droga szybkiego ruchu (B^Ecznik) in CodePage=windows-1252 Cannot represent String=21,Droga krajowa (B^Ecznik) in CodePage=windows -1252 Cannot represent String=21,Droga wojew\363dzka (B^Ecznik) in CodePage=windows-1252 Cannot represent String=21,Wie[ (>5 tys.) in CodePage=windows-1252 Cannot represent String=21,Wie[ (>5 tys.) in CodePage=windows-1252 Cannot represent String=21,Restauracja (AmerykaDska) in CodePage=windows-1252 Cannot represent String=21,Restauracja (ChiDska) in CodePage=windows -1252 Cannot represent String=21,Restauracja (Mi^Ydzynarodowa) in CodePage=windows-1252 Cannot represent String=21,Restauracja (WBoska) in CodePage=windows -1252 Cannot represent String=21,Restauracja (MeksykaDska) in CodePage=windows-1252 Cannot represent String=21,Restauracja (P^Eczki) in CodePage=windows -1252 Cannot represent String=21,Restauracja (WegetariaDska) in CodePage=windows-1252 Cannot represent String=21,Kr^Ygle in CodePage=windows-1252 Cannot represent String=21,Sklep odzie|owy in CodePage=windows-1252 Cannot represent String=21,Wypo|yczalnia samochod\363w in CodePage=windows-1252 Cannot represent String=21,Gara| in CodePage=windows-1252 Cannot represent String=21,Sprzeda| samochod\363w in CodePage=windows -1252 Cannot represent String=21,Sklep |eglarski in CodePage=windows-1252 Cannot represent String=21,S^Ed in CodePage=windows-1252 Cannot represent String=21,O[rodek kultury in CodePage=windows-1252 Cannot represent String=21,Wi^Yzienie in CodePage=windows-1252 Cannot represent String=21,Stra| po|arna in CodePage=windows-1252 Cannot represent String=21,SBupek in CodePage=windows-1252 Cannot represent String=21,PrzystaD in CodePage=windows-1252 Cannot represent String=21,L^Edowisko helikopterowe in CodePage=windows -1252 Cannot represent String=21,Wie|a in CodePage=windows-1252 Cannot represent String=21,yr\363dBo in CodePage=windows-1252 Cannot represent String=21,Pla|a in CodePage=windows-1252 Cannot represent String=21,Przyl^Edek in CodePage=windows-1252 Cannot represent String=21,SkaBa in CodePage=windows-1252 Which makes sense if codepage 1252 doesn't handle Polish (hex 0x15, decimal 21). NB the non ascii characters in above are messed up by my cutting and pasting. Checking the French, on my Garmin device, the type descriptions now display accents correctly. Ticker

2 14

Test cases for possible is-in-hook
by Gerd Petermann 06 Jan '20

06 Jan '20

Hi all, this is a follow up of http://gis.19327.n8.nabble.com/Commit-r4398-revert-changes-from-r4397-is-in… Attached is a new file which contains additional ways w28 .. w30 and w26 was changed from expected="?" to "in". The new ways are all very close to the residential polygon(s), but completely outside. I think w26 and w30 show very common cases in OSM. Some mappers prefer to "glue" landuse polygons to highways, others don't. There are probably good reasons for both methods. Because of the poor precision the current code in mkgmap adds mkgmap:residential to both of them. See http://gis.19327.n8.nabble.com/is-in-filter-tp5890564p5890566.html where Carlos stated that this would be welcomed (at least if the ways were e.g. highway=secondary instead of footway). If I change the code to be a lot more precise w30 would not be tagged. On the other hand, if you ask for landuse=cemetery you probably don't want to change a cycleway next to it. Any ideas how to handle this dilemma? Gerd P.S. In my hometown the cemetery expanded during the years and it now stretches across a residential road "Lehmkuhlenweg". See https://www.openstreetmap.org/way/11760536 I think in reality the cemetery is split into two parts, there are gates on the footways and barrier=fence or barrier=hedges along the road, but nobody mapped them until now.

4 6

New branch is-in for experiments on style function is_in
by Gerd Petermann 02 Jan '20

02 Jan '20

Hi all, with the help of Ticker I see a way to implement an is_in style function I've created branch is-in to experiment with this. Sorry for the different spelling is-in in the branch name! Unfortunately I got no response regarding the contents of the file is-in-hook-samples-v2.osm posted here: http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook-tp5954103… So, Ticker and I have to guess what the function should do when a way or polygon crosses or touches the boundary of a polygon with the given attribute. The code in r4400 implements a function is_in with three parameters which returns either true or false. It allows a rule like this in the lines file: highway=* & bicycle!=* & (is_in(landuse,cemetery,all) = true | is_in(amenity,grave_yard,all) = true) {add bicycle=dismount} or this one in the polygons file: # render building only when completely outside of a residential area building=* & building!=no & is_in(landuse,residential,any)=false [0x13 resolution 24] A BIG question mark is the handling of rules which change the tags of polygons. Assume you have a rule like this in polygons: landuse=residential | landuse=commercial {set mylanduse=xyz} and somewhere else building=* & building!=no & is_in(mylanduse,xyz,any)=false [0x13 resolution 24] It might not be obvious but this could produce more or less unpredictable results as it depends on the order in which elements are processed. So, Ticker suggested to say "results of the is_in function are undefined when tags of polygons are changed". I hope we can change this to something like "changing tags of polygons in the style rules has no effect on the results of the is_in function" by creating copies of elements before the style rules are applied. Gerd

3 2

Re: [mkgmap-dev] [mkgmap-svn] Commit r4401: fix compilation problems
by Ticker Berkin 30 Dec '19

30 Dec '19

Hi Gerd Do you want me to do anything with this at the moment? I could add default methods and change the irrelevant implementations back to the same as trunk, tidy up... or whatever. I've checked out the branch loaded, but I doubt if I can update it so I'd have to send you patches. In the is-in function, I considered the processing happening in two stages: On the first invocation the original wayMap is scanned for closed polygons meeting the tag requirements and this sub-list is held in a new, possibly spacial structure. Then, on this and all subsequent invocations, the (bounds of the) actual element that the rule/function is being applied to is used select candidates from the above list and these are examined according to the accuracy required. If it is felt the changing polygon tags shouldn't affect processing, then the first stage could be moved from first invocation to the point at which the wayMap is passed in. Actually, probably best just to do this anyway; there will be no difference in cost unless the function is never invoked and there is no need to keep the Way structures with the tags/values anyway after this processing. Ticker On Mon, 2019-12-30 at 11:12 +0000, svn commit wrote: > Version mkgmap-r4401 was committed by gerd on Mon, 30 Dec 2019 > BRANCH: is-in > fix compilation problems > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4401 > _______________________________________________ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-leave(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn

1 0

New branch for default typ file
by Gerd Petermann 21 Dec '19

21 Dec '19

Hi all, I've created a new branch now with changes proposed by Joris. I hope this helps bringing this forward. Attached is a document from Joris. Gerd

11 52

Re: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is-in-landuse option)
by Gerd Petermann 21 Dec '19

21 Dec '19

Hi Jan, the currently implemented hook never splits a way, it just calculates the tag mkgmap:residential with a very lazy and unprecise test. It was meant to detect buildings inside residential areas. It works quite well for that, but produces more or less unprecise results for the highways in the example file. There are some other routines which split ways, for example roundabouts or p-shaped roads are split. Maybe you see that effect in your map. The RoadMerger sometimes produces p-shaped ways. I think it would be possible to split an (unclosed) way where it enters or exits a given polygon type, maybe it would make things easier to handle in the stye. Question is if that should also be done for places where the ways don't share a node with the polygon (can cause line distortion), an example would be w15 which would be split into 3 parts. It's likely that the way would no longer be straight after that because of the poor Garmin resolution. In fact we want such a split method to be able to create map tiles with a non-rectangular shape, but that is another problem. I'll post a new file containing a few more special cases in a new thread. Gerd ________________________________________ Von: jan meisters <jan_m23(a)gmx.net> Gesendet: Samstag, 21. Dezember 2019 00:31 An: Gerd Petermann Betreff: Re: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is-in-landuse option) Hi Gerd, ok, I didn´t know about this radius. That really explains a lot of what I called erratic results. So straddle means a line to be split accordingly? I haven´t imagined such a split possible on non existing points, that´s why I mentioned it happening in r4398. For lines travelling on borders of polygons I´m not sure if straddle is always good. Treat overlapping/touching polygons as one - yes, reasonable. But I never really faced the effect on areas when trying the hook. Jan Am 20.12.2019 um 23:12 schrieb Gerd Petermann <gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>: Hi Jan, my understanding of Tickers definition is that straddle means partly in and partly out. I didn't look at the results produced with any mkgmap version. I want to define what results we want to get. I agree that the track is outside of the landuse=residential way. Current mkgmap searches a radius of ~ 3 m for a residential area, that might explain the wrong result. I agree that we probably want in for w26. Probably it would be best to combine overlapping or touching polygons so that they are treated like a single one. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von jan meisters <jan_m23(a)gmx.net<mailto:jan_m23@gmx.net>> Gesendet: Freitag, 20. Dezember 2019 22:54 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is-in-landuse option) Hi Gerd, great job! Concerning my english: I understand straddle as effectively outside, correct? Until now I only focussed on lines. In the samples every scenario of them looks good to me, if straddle=out. If not, hmm. For w26 i expect in. Attached is another example, stripped from OSM for residential also. By 4397 the whole track is rendered as in. With patched 4398 the line is split at the top west point of the residential llanduse and from there processed as in to the east. But I would expect it as completely out. (The original is here: https://www.openstreetmap.org/way/17937104, and I ask for allotments as in) Jan Am 20.12.2019 um 19:56 schrieb Arndt Röhrig <arndt(a)speichenkarte.de<mailto:arndt@speichenkarte.de><mailto:arndt@speichenkarte.de>>: Hi Gerd, with r4397 i used this: mkgmap:lu:cemetery=* &! ((route_mtb=*|route_icn=*|route_ncn=*|route_lcn=*|route_rcn=*) | bicycle~'yes|official|designated|dismount|ok') {set rad=nein} and this highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10112 resolution 24 continue] highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10113 resolution 23-22 continue] highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10114 resolution 21-21 continue] highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10115 resolution 20-20 continue] highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10112 resolution 24 continue] highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10113 resolution 23-23 continue] highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10114 resolution 22-21 continue] highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10115 resolution 20-20 continue] I think it´s nice, to expand the function mkgmap:lu:cemetery, so that some other polys (playground, military, deponie etc) work with this. i don´t understand all mails, because my english is .....(: Thank you for all the work you do! best regards Arndt Gerd Petermann < gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com>> hat am 20. Dezember 2019 um 18:32 geschrieben: Hi all, attached is an OSM file with various test cases. Assume we want to get the result for landuse=residential. Please load it in JOSM and search for expected=in or expected=out or expected=straddle and finally expected="?" and let me know as soon as possible if you don't agree with anything. (each case has a different name for the object to be tested. The cases with "?" are special, I think b9 and b10 are not important, but the others are very usual in real OSM data. The existing ResidentialHook would add mkgmap:residential to b13, b14 and w26. @Ticker: The residential areas around b13 and b14 show the special case with multipolygons. The hook probably "sees" something like the b13 example when looking at b14 because the multipolygons are cut into pieces without holes before the hook is executed. @all: Would be very good to get some feedback on this, even if you think that you don't need the hook for your style. Gerd ________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin < rwb-mkgmap(a)jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 20. Dezember 2019 13:49 An: mkgmap development Betreff: Re: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is-in-landuse option) Hi Given the complexity and cpu cost of calculating this, the various questions, hence answers possible and it has to be done for all elements if the --is-in option is given what about making it a function instead. This means that it only needs to be computed for elements where the answer matters and, as a parameter, the question about what the required is-in means can be asked. eg, in points: if building=church and is-in('landuse', 'cemetery') {add name='Chapel of Rest'} in lines: if highway=* and is-in('landuse', 'cemetary', 'fully') {add bicycle=no} etc. Above are just approximations of how the parameters might work. The various levels of is-in that might be required should be considered, as per Gerd's comments. For some of the examples that have been given for use of this facility, I feel they should really be solved by accurate tagging. @gerd Although it looked like it, I didn't really intend that elements were tagged with NO if no part was within the polygon. Ticker On Fri, 2019-12-20 at 10:43 +0000, Gerd Petermann wrote: Hi all, I think I have now the needed methods to be able to distuingish if a given node is inside, outside or "on boundary" of a polygon. In (1) Ticker suggested to use these rules to determine what tag the hook should add either IN, OUT, or STRADDLE as a tag value. The current implementation in ResidentialHook adds either no tag (meaning outside) or a tag with the value "yes" or the name of the found residential area. The typical rule to use this tag would be mkgmap:residential=* {do something} I think we should NOT add the tag with a value OUT, else the above rule will fail. On the other hand, I assume that nobody use a rule like mkgmap:residential=* & mkgmap:residential!=yes {do something with the name contained in mkgmap:residential} I think it was not a good idea to use the name, I used it for debugging. Open question: Should we really just count points? Assume you have a U-shaped cemetery and a highway=footway with just two points starts inside the left upper part and ends inside the right upper part. Most of the way would be outside but the points are inside the cemetery. No idea how often this happens, but the result would be "IN" with Tickers rules. Even when you add (barrier=gate) nodes on the boundaries of the cemetery the result is still "IN" I woud call this result wrong and expect a value like STRADDLE. Gerd (1) http://gis.19327.n8.nabble.com/Commit-r4397-implement-and-documen t-new-option-is-in-landuse-value-value-tp5953495p5953703.html ________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von svn commit < svn(a)mkgmap.org.uk<mailto:svn@mkgmap.org.uk><mailto:svn@mkgmap.org.uk>> Gesendet: Mittwoch, 18. Dezember 2019 09:24 An: mkgmap-svn(a)lists.mkgmap.org.uk<mailto:mkgmap-svn@lists.mkgmap.org.uk><mailto:mkgmap-svn@lists.mkgmap.org.uk>; mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> Betreff: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is -in-landuse option) Version mkgmap-r4398 was committed by gerd on Wed, 18 Dec 2019 revert changes from r4397 (--is-in-landuse option) The test is too lazy and requires a lot more work. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4398 _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1 0

Bay polygons points conversion
by David 20 Dec '19

20 Dec '19

To Ticker and Gerd, My purpose is to delete what I considerer an error : like a county is a part of a country and it is not rendered by a dedicated polygon, bays are parts of sea/ocean and as on most of paper map, they should be rendered as a feature/landmark, ie their name. Using a polygon for a bay hides the holes made for islands and islets in sea polygons. This is the problem I encountered in Clew Bay (Ireland). To avoid that, I commented the corresponding line in polygons style file and I changed points style file like this to preserve bays name : if (mkgmap:area2poi=true) then natural=bay & name=* [0x6503 resolution 20] else #all other points rules ... end This does exactly what I want : to replace a bay named polygon by a Garmin defined POI with the name displayed on the map like other bays around Ireland. The fact that I disable all other POIs created to make a possible search of polygons is not the initial question. I can easily add the ones I want in the if statement. To dig the hole, if I add a POI to a polygon to make it searchable (and to bloat my display with the name of the polygon), name and other informations attached to the polygon are redundant and shall be deleted (informations and name shall be attached to the POI). Doing this is now my next step to complete the searchable places in my map (that is your fault, you inspired me !). But I fear it is not possible without doing some changes in mkgmap. Am I right ? David

2 1

Commit r4398: revert changes from r4397 (--is-in-landuse option)
by svn commit 20 Dec '19

20 Dec '19

Version mkgmap-r4398 was committed by gerd on Wed, 18 Dec 2019 revert changes from r4397 (--is-in-landuse option) The test is too lazy and requires a lot more work. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4398

5 5