- mkgmap-dev - The mkgmap lists

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

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