May 2015 - mkgmap-dev - The mkgmap lists

[Patch v1] use role=label member to place POI
by Gerd Petermann 28 May '15

28 May '15

Hi all, quite a lot of mp-relations have a node member with role=label. The attached patch changes the code for the --add-pois-to-areas option so that the location of this node is used for the generated POI when the name of the node and the name of the relation are equal (like with role=admin_centre) A binary is here: http://files.mkgmap.org.uk/download/268/mkgmap.jar Gerd

4 6

splitter r423
by Gerd Petermann 24 May '15

24 May '15

Hi all, please note the new option --wanted-admin-level in r423. For details see http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&path=%2F&rev=… and the discussion about duplicate cities: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2015q2/023603.html Gerd

3 3

Duplicate cities
by Gerd Petermann 22 May '15

22 May '15

Hi all, I've noticed the following problem with boundary relations (type=boundary, boundary=administrative), e.g. http://www.openstreetmap.org/relation/170953 is cut into pieces with the attached areas.list By default, splitter will not keep them complete, and it is likely that this relation appears in more than one tile. When you use --add-pois-to-areas mkgmap will generate a POI based on the existing data, and this POI will have the tag place=city (for the example), so for each tile we calculate different coordinates for the city POI. I guess this happens with other relations as well. You can solve this particular problem by telling splitter to keep all administrative boundaries complete, but that will produce a lot more data in each tile: --boundary-tags=administrative So, I see two possible solutions: 1) change splitter so that it keeps mp-relations complete when they have a tag like place. A new option could specify a list of those tags . 2) change mkgmap so that it doesn't generate a POI for mp-relations with incomplete outer ways. What do you think? Gerd

3 10

housenumber2 branch ready for merge?
by Gerd Petermann 22 May '15

22 May '15

Hi all, I want to merge the branch. I don't have much more time to improve the code, so all I want to do is fix severe errors. I think the best way to find out if it works is to do the merge and see what happens. Unfortunately, I'll not have time to fix things during the next week, so please test the branch with your style and let us know if it worked well. The merge should happen on Monday, June 1. Alternative: Merge today. Ciao, Gerd

1 0

Re: [mkgmap-dev] Named bridges not displaying
by Gerd Petermann 21 May '15

21 May '15

Hi Dave, I agree that the rules to set a "name" are very confusing, esp. when it comes to roads. I guess one reason is that it took a while to discover that a map object can have 4 labels, another point is that we don't try to explain the Garmin format in this manual, instead we presume that the reader knows the details of the Garmin format quite well. Maybe it would help to add a chapter with links to the corresponding manuals and wiki pages. If you have the time, please propose improvements, the sources are almost normal text files. Reg. your questions: Why not addabel ? I thought you want to see the bridge name in the map. If that is the case, you have to set mkgmap:label:1 . If you want to be able to find the bridge in address search, you can use addlabel without problems. Why doesn't set name='${bridge:name}' work? Because it sets the tag name to a new /different value. If it is not followed by a rule that uses this value to set mkgmap:label:* you will not see a change. Gerd From: daveswarthout(a)gmail.com Date: Wed, 20 May 2015 12:09:55 -0700 Subject: Re: [mkgmap-dev] Named bridges not displaying To: gpetermann_muenchen(a)hotmail.com Thank you very much. That worked like a charm. As for the style manual, 4.3.6. nameThis sets the first label of the element but only if it is not already set. This is a helper action. The sameeffect can be produced with different notations as it is shown in the following example where all threelines have the same effect. {name '${name} (${ref})' | '${ref}' | '${name}'} {add mkgmap:label:1='${name} (${ref})' | '${ref}' | '${name}'} mkgmap:label:1!=* {set mkgmap:label:1='${name} (${ref})' | '${ref}' | '${name}'} How one would determine that this is a situation when one must assign a mkgmap label is beyond me. I could have read that description a thousand times and not figured out what to do. What's missing is WHY one would use the name directive in this way. And then, some information about the use of mkgmap:label:1 in these circumstances would be helpful too. In scanning the manual I noticed another directive, addlabel which would assign the next available label level. Why didn't you use that? I'm thinking it's because you already knew the tags for these two bridges so you knew mkgmap:label:1 was not being used. But wouldn't addlabel be a "safer" way to go about this in the general case? One last question: During my struggles I tried using the set command, {set name='${bridge:name}' }, to replace the name of the section of highway that crosses the bridge with the bridge name but it didn't work. Could you venture a reason for that? On Wed, May 20, 2015 at 10:02 AM, Gerd Petermann <gpetermann_muenchen(a)hotmail.com> wrote: Hi Dave, the name action has no effect when mkgmap:label:1 is already set. You may move your rule before those that use the highway name, or you can use bridge=* & bridge:name=* {set mkgmap:label:1= '${bridge:name}'; echotags ""} See style manual section 4.3.6 Gerd From: daveswarthout(a)gmail.com Date: Wed, 20 May 2015 09:49:43 -0700 To: mkgmap-dev(a)lists.mkgmap.org.uk Subject: [mkgmap-dev] Named bridges not displaying Thanks for all the good effort on the exit_to and destination issues. Everything is working well for me now. I discovered another problem that might be simple to fix, or maybe there's something that I'm doing wrong. There are two named bridges in my current area but the names do not display on my maps. I placed this rule in my lines style file: bridge=* & bridge:name=* {name '${bridge:name}'; echotags ""} here is the stderr output 221689337 - [highway=tertiary,ref=CR 48,mkgmap:label:2=Lower Smith River Road (CR 48),bridge=yes,name=Lower Smith River Road,bridge:name=Jack Franz Bridge,surface=asphalt,mkgmap:street=Lower Smith River Road,mkgmap:label:1= CR48 Lower Smith River Road,ele=1] 336150197 - [highway=residential,mkgmap:street=Goodpasture Road,mkgmap:label:1=Goodpasture Road,covered=yes,bridge=yes,bridge:name=Goodpasture Bridge,name=Goodpasture Road] The bridge name does not appear on the compiled maps. Any ideas or suggestions? Dave-- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

2 1

[Patch v2] use role=label member to place POI
by Gerd Petermann 21 May '15

21 May '15

Hi all, sorry, v1 was missing a check for null , attached is v2, the binary is here: http://files.mkgmap.org.uk/download/269/mkgmap.jar To ease testing I've added a log message with error level ,e.g. ... using label node as location for POI for rel 334443 Goiás at -15.933471/-50.140561 it will also complain loudly when the node is not used because the names don't match: ... rel http://www.openstreetmap.org/relation/331515 ,node with role label is ignored because it has a different name Please suggest better text for the messages. These messages show were the patch changes something, it will be changed to debug/warn level before committing the patch. If I got that right, Marcio and Anor propose to always use the label node to place the generated POI for admin_level=10 boundaries, but I see one potential problem here: The node might also be used by different relations, and in that case we will produce different POI at the same location. I think this is something we want to avoid. One more point I am not sure about: The node in the mp-relation is only used when both the relation and the node have a name tag (or whatever the name-tag-list tells mkgmap to use as name), and when these are equal. Do you see a case where we should use the node even if one of the name tags is missing? Gerd

3 4

Request for feature: show wrong roundabouts
by Thorsten Kukuk 21 May '15

21 May '15

Hi, from time to time I see this in the log files: Attention: Tile contains both drive-on-left (1) and drive-on-right roads (15389) The one "drive-on-left" road is clearly a bug in the OSM data. But finding that is pretty hard (I found one once by accident ...). I wanted to try to implement this myself, but I currently don't see that I have the time to dig into the code myself, that's why I write here my idea: Could we add an option (--x-report-wrong-direction or something similar), and if drive-on=left or drive-on=right is set, write the roads with the wrong direction into the log file? If drive-on= isn't set at all or to "detect", nothing should be written. So, additonal to increasing the counter, write the ID at that time to the log, too. Thanks, Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

3 7

Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI
by svn commit 21 May '15

21 May '15

Version mkgmap-r3573 was committed by gerd on Sun, 10 May 2015 admin_centre-v1.patch: avoid to create duplicate POI It implements the following: When POIGeneratorHook creates a POI for a type=boundary relation with boundary=administrative it searches for a role=admin_centre member in that relation. If one is found, the generated POI will use the coordinates of this member. I see no easy way to compare the tags of the existing node with those of the generated POI, so as a second step, StyledConverter detects when a POI with the same type and name (or empty name) is created at the same Garmin coordinates (after style processing) If that is true, the latter one is ignored and an info message is logged. Maybe for certain types this should be changed to check for a radius rather than equality, but that would require complex configuration.

6 9

Suppress Warnings for different Code page
by Felix Hartmann 20 May '15

20 May '15

When combinining .img files into a mapset - there is no need to warn about different codepages if the added maps do not contain anything to search for. So Warnings of the following types: WARNING: input file 75740000.img has different code page 1252 WARNING: input file 75740000.img has different charset type 10 WARNING: input files have different code pages are not needed if you for example add contourlines only maps into a mapset ofther maps. Could there be a possibility to suppress remove those code page and charset type warnings? It would make it easier to read my logs for real errors... -- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich

1 1

Named bridges not displaying
by Dave Swarthout 20 May '15

20 May '15

Thanks for all the good effort on the exit_to and destination issues. Everything is working well for me now. I discovered another problem that might be simple to fix, or maybe there's something that I'm doing wrong. There are two named bridges in my current area but the names do not display on my maps. I placed this rule in my lines style file: bridge=* & bridge:name=* {name '${bridge:name}'; echotags ""} here is the stderr output 221689337 - [highway=tertiary,ref=CR 48,mkgmap:label:2=Lower Smith River Road (CR 48),bridge=yes,name=Lower Smith River Road,bridge:name=Jack Franz Bridge,surface=asphalt,mkgmap:street=Lower Smith River Road,mkgmap:label:1= CR48 Lower Smith River Road,ele=1] 336150197 - [highway=residential,mkgmap:street=Goodpasture Road,mkgmap:label:1=Goodpasture Road,covered=yes,bridge=yes,bridge:name=Goodpasture Bridge,name=Goodpasture Road] The bridge name does not appear on the compiled maps. Any ideas or suggestions? Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

1 0