May 2015 - mkgmap-dev - The mkgmap lists

levels in style aren't processed correctly
by Andrzej Popowski 20 May '15

20 May '15

Hi, I have defined a rule in style like this: highway=path [0x16 road_class=0 road_speed=0 level 0] When I compile map with "--levels=0:24", then I get paths correctly. When I use option "--levels=0:23", then paths are missing. I would expect paths on level 0 regardless of resolution. -- Best regards, Andrzej

4 11

question reg. exits
by Gerd Petermann 20 May '15

20 May '15

Hi all, I just noticed that mkgmap treats POI with 0x2000 <= type < 0x2800 special. It looks for the tags exit:to=* and exit:facility=* to add extra information to the POI. This info is shown when you click on an exit in Basecamp, it shows the fields Name, Description, and Overnight Parking. The source was added with r984 in 2009 and it seems nobody noticed that these tags don't exist in OSM anymore (or maybe they were typos)? Or maybe that were meant to be set in the style? Gerd

4 8

Re: [mkgmap-dev] levels in style aren't processed correctly
by steve.sgalowski 19 May '15

19 May '15

The only prob I have with the codes is saying below 17 is to small to split but not saying this on all maos though Stephen -------- Original message -------- From: Andrzej Popowski <popej(a)poczta.onet.pl> Date:20/05/2015 8:45 AM (GMT+10:00) To: mkgmap-dev(a)lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] levels in style aren't processed correctly Hi Steve, > I don't understand this. If you have no --levels option then the > default should be used, which has a maximum of 4. Looks like there is no defaults now, or maybe only level 0 gets a default resolution. > What do you think that the message text should be? Maybe something like "'level 1' is used in style while its resolution is not defined in option 'levels=' nor "overview-levels=". > What are the conditions to cause this error? My previous analysis was wrong. This is what I'm doing: - I have modified default style changing some "resolution xx" to "level 0", "level 1" or "level 2". - I have commented "levels=" and "overview-levels=" in "options" file. Now I run compilation with following command line options: 1) --levels=0:22,1:21,2:20 --gmapsupp --no-tdbfile 2) --levels=0:22,1:21 --gmapsupp --no-tdbfile 3) --levels=0:22,1:21 --overview-levels=4:16 --gmapsupp --no-tdbfile Compilation 1) goes correctly. Compilation 2) ends with an error. Compilation 3) creates a map. Map for case 2) consist of only layer 0 and 1, so all references to "level 2" in style could be ignored. I would expect successful compilation at case 2). Next observation is that case 3) shouldn't be different from case 2), there is no definition for "level 2" either. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1 0

housenumber2: distance too large I don't understand
by Thorsten Kukuk 19 May '15

19 May '15

Hi, I'm seeing a log of SEVERE messages from the housenumber2 r3589 branch. Most of them are pretty clear, there where very long cycleways in between the house and the street and all connections where missing. Adding all missing connections fixed that. But there is one left, where I don't understand what the problem is: 2015/05/19 03:30:49 SEVERE (ExtNumbers): 71200089.osm.pbf: distance to road too large, road id=6675816, Geesterseveldweg house 6(1) http://www.openstreetmap.org/node/2917181493 What's the problem with this address? Thanks, Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

2 4

housenumber2 branch r3589
by Gerd Petermann 19 May '15

19 May '15

Hi all, I think I've now found a solution for most of the known problems reg. address search, for details see svn log: http://www.mkgmap.org.uk/websvn/log.php?repname=mkgmap&isdir=1& The remaining work to do is cleanup and maybe performance improvements, I don't plan any more significant changes in the algorithms as long as nobody complains. If you want to try the branch with your style, please make sure to understand the new special tags mkgmap:numbers=false and mkgmap:execute_finalize_rules=true in combination with inc/address. Attached is the diff between the default style in the branch and that in trunk. Note that mkgmap uses by default all OSM elements with a tag addr:housenumber or mkgmap:housenumber. Even if the style doesn't create any map object for the element, the numbers are used, so the new tags are used to make sure that the rules in inc/address are used for all of them and to allow the exclusion. A few hints: The img files produced with the branch are typically larger, esp. in areas where the trunk version did not work well (e.g. heavy usage of addr:place) The throughput is a few percent slower. Main reason is the complex search for nearest roads. Maybe I can find a better algorithm for this in the future. It would be great to get some feedback, esp. when you think that rather good / clear OSM data is not interpreted correctly, but also when you think the branch works fine ;-) Gerd

3 5

Commit: r3597: corrections for process-exits option
by svn commit 18 May '15

18 May '15

Version mkgmap-r3597 was committed by gerd on Sun, 17 May 2015 corrections for process-exits option - evaluate destination:forward and destination:backward - make sure that evaluated tags are not removed if they are not used in the style, esp. exit_to

3 3

Commit: r3598: fix possible NPE when way has destination:forward or destination:backward tag
by svn commit 18 May '15

18 May '15

Version mkgmap-r3598 was committed by gerd on Mon, 18 May 2015 fix possible NPE when way has destination:forward or destination:backward tag

1 0

FW: Routing parameters
by Gerd Petermann 17 May '15

17 May '15

From: gpetermann_muenchen(a)hotmail.com To: daveswarthout(a)gmail.com Subject: RE: [mkgmap-dev] Routing parameters Date: Sat, 16 May 2015 12:02:22 +0200 Hi Dave, not sure what the problem is. The subst filters are just used to remove some blanks or semicolons. The rest is more or less "a list of alternative expressions separated with a vertical bar", you can search for that term in the style manual: http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf I've never tried these options because I use my GPS only for cycling, but my understanding is that the types 0x08 and 0x09 are special as they instruct the Garmin device to use the name of the road for the destination hint, and these rules are used to fill this name with useful information. Does that help? Gerd From: daveswarthout(a)gmail.com Date: Fri, 15 May 2015 17:51:13 -0700 To: mkgmap-dev(a)lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Routing parameters Yes, as you can see above, I understand the intent of those two options. But if someone could further explain what's happening in the rule, I would be most appreciative. I'm guessing the first part assigns a name or ref if one appears in the tagging but understanding the logic of the series of "subst" filters following that is, for a newbie, quite challenging. On Fri, May 15, 2015 at 12:17 PM, GerdP <gpetermann_muenchen(a)hotmail.com> wrote: Hi Dave, please check the documentation for --process-destination and --process-exits: http://www.mkgmap.org.uk/doc/options If I got this right, these option mark exits so that Garmin knows where they are where they lead. Gerd Dave Swarthout wrote > I am curious to know how mkgmap handles the display of and text to speech > aspects of motorway junctions. It's hard to test for this without actually > creating a route and then driving it to see and hear what the Garmin is > doing with the data or to discover where it gets the information from. > > I'm assuming that whatever one puts in the exit_to=* tag gets displayed > and > spoken by the Garmin "assistant". Does mkgmap ever use the destination=* > tag, and if so under what circumstances? > > I found this rule in the lines style sheet, but I do not understand it > well > enough to help me answer my question > > (highway=motorway_link | highway=trunk_link) & mkgmap:exit_hint=true & > mkgmap:dest_hint=true > { name '${destination:ref|subst: =>} ${destination|subst:;=> |subst:/=> > }' | > '${ref|subst: =>} ${destination|subst:;=> |subst:/=> }' | > '${destination|subst:;=> |subst:/=> }' | > 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_name}' | > highway=road > 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_exit_to}' | > 'Exit ${mkgmap:exit_hint_exit_to}' | > 'Exit ${mkgmap:exit_hint_name}' | > 'Exit ${mkgmap:exit_hint_ref}' > } > > > As always, thanks in advance to any help you can provide. > > Dave > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@.org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Routing-parameters-tp5844762p5844766.html Sent from the Mkgmap Development mailing list archive at Nabble.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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

3 7

options --process-destination and --process-exits
by Gerd Petermann 17 May '15

17 May '15

Hi all, the discussion with Dave http://gis.19327.n5.nabble.com/Routing-parameters-tp5844762.html forced me to look at the sources for these two options --process-destination and --process-exits I think there are a few problems in the source LinkDestinationHook.java: I think one is a typo: It evaluates direction:forward=* and direction:backward=* instead of destination:forward and destination:backward. Another is a logical error: Some tags which are evaluated are not mentioned in the getUsedTags() method. I also see that the source doesn't care about nodes with exit_to=* tag when the node is part of a motorway_junction: http://www.openstreetmap.org/node/21992225 As a cyclist I did not care about these functions, but I will review the sources now and try to understand in detail what the options are supposed to do. Gerd

1 1

License and copyright text defects
by Paco Tyson 16 May '15

16 May '15

Hi all, I started customizing the copyright/license text for my map. I found some strange results that I want to share with you. This is the license and copyright text : license.txt : My license text Second line of license Third and last line, blabla êß copyright.txt : Beginning of the copyright text Second line of the copyright text, including accentuated characters : éàß Third and last line of the copyright text For each run, I run mkgmap v3539, create a .gmap map with jmc_cli, install it on Basecamp thanks to MapManager. I then install it on my Oregon 600 via MapInstall. First run : --license-file=license.txt and --copyright-file=copyright.txt JaVaWa GMTK displays : My license text Second line of license Third and last line, blabla êß BEGINNING OF THE COPYRIGHT TEXT SECOND LINE OF THE COPYRIGHT TEXT, INCLUDING ACCENTUATED CHARACTERS : ÉÀSS THIRD AND LAST LINE OF THE COPYRIGHT TEXT Basecamp displays : BEGINNING OF THE COPYRIGHT TEXT My license text Second line of license Third and last line, blabla êß SECOND LINE OF THE COPYRIGHT TEXT, INCLUDING ACCENTUATED CHARACTERS : ÉÀSS THIRD AND LAST LINE OF THE COPYRIGHT TEXT Oregon 600 displays on the Info page of the map : ©SECOND LINE OF THE COPYRIGHT TEXT, INCLUDING ACCENTUATED CHARACTERS : ÉÀSS ©THIRD AND LAST LINE OF THE COPYRIGHT TEXT The first line of the copyright file is displayed before the license block on Basecamp and it is missing on the GPS device. Second run : --license-file=license.txt and --copyright-file=copyright.txt but copyright.txt content is : "Only one line" JaVaWa GMTK displays : My license text Second line of license Third and last line, blabla êß PROGRAM LICENCED UNDER GPL V2 ONLY ONE LINE Basecamp displays : My license text Second line of license Third and last line, blabla êß ONLY ONE LINE PROGRAM LICENCED UNDER GPL V2 Oregon 600 displays on the Info page of the map : ©ONLY ONE LINE Note how the lines of the copyright block are switched between GMTK and Basecamp. Independently of the exposed results above, I have a few questions and remarks : - Despite providing a lower case copyright text, the result text is in upper case. Is it done by mkgmap ? Is it a Garmin format limitation ? - In the default license/copyright text, one can read "Program released under the GPL" and "PROGRAM LICENCED UNDER GPL V2". I assume it's the mkgmap license, instead I'd expect here the license of the produced Garmin map. Documentation remarks : --copyright-message=note Specify a copyright message for files that do not contain one. What files are we talking about ? The OSM data files ? By the way, we could add here that --copyright-message is ignored if --copyright-file is also provided. --copyright-file=file Specify copyright messages from a file. Note that the first copyright message is not displayed on a device, but is shown in BaseCamp. The copyright file must include at least two lines. Based on my tests, one can specify a one-line copyright file, mkgmap adds the line "PROGRAM LICENCED UNDER GPL V2", the last sentence is not true anymore. --license-file : I don't understand "All entries of all maps will be merged in the overview map.". What are "all maps" ? Is the overview map used to store the overview levels or the gmapsupp.img file ? Cheers, Paco

2 2