November 2009 - mkgmap-dev - The mkgmap lists

[PATCH v1] Fix Nuvi routing regression (rebloat Table A)
by Mark Burton 25 Nov '09

25 Nov '09

Way back in September, revision 1228 changed one of the routing data structures (Table A) to have one entry per road rather than one entry per arc (a road contains 1 or more arcs). This reduced the number of Table A entries required which made the maps smaller and, hopefully, improved the routing because the routing centres could be larger. However, I have been trying for some time now to find why the routing is partially broken on my Nuvi 255 for certain combinations of mkgmap version, extra patches and the options used when compiling the map. The same maps work fine (as far as I have tested them) on mapsource and the etrex. Not one routing failure occurred on those that could not be attributed to something else. So, after much dicking around with options, patches, etc., I think the Table A size reduction is the culprit. The attached patch essentially undoes the good work from September (although this code is simpler than what was there before). With this, the Nuvi barfs no more. The downside is that the map has grown again. Can't say whether the routing quality has changed. Rolled into this patch is another reversion. The value of MAX_ARC_LENGTH has been reverted to 75000. Never did believe that was the real solution. Please give it a go and report any findings. Mark PS - Marko, please try this and see if the routing problems you were experiencing still occur. Also, please try it on your Nuvi user and see if their problems go away. PPS - the one pleasing aspect of all this is that if it proves to be a sensible change, the node-reduction patch that I keep banging on about will see the light of day.

1 1

tag test "start with"
by Ben 25 Nov '09

25 Nov '09

Hi mkgmap gurus, Im currently trying to convert some POI lists into img format with mkgmap. Depending on the first character of the POI name, different actions should be performed. I tried the following: name=T* {name '${name}'} [0x0101 level 4] name=M* {name '${name}'} [0x0102 level 4] name=E* {name '${name}'} [0x0103 level 4] what results in the error message "Error in style: Error: (points:1): Stack size is 2 Could not open style null" As far as I understand the syntax, I can only test tags for equality, not if they contain certain strings. Does anyone have a good idea idea for how to achieve the desired differentiation? Thanks, Ben

2 2

[PATCH v1] increase Table B size
by Mark Burton 25 Nov '09

25 Nov '09

Support larger Table B sizes. Until now, we have limited Table B to less than 0x40 entries but by using an extra byte to hold the Table B index in RouteArc objects, the number of entries can be increased up to a new limit of 0x100. Just discovered that Table B can actually be larger than we have been using. Table B overflow is one of the criteria for dividing a route centre so by allowing them to be larger, it should reduce the number of route centre splits. Having said that, on the GB map data, only a few Table B's grew larger than the previous limit so I think the benefit is probably marginal. Still, for complex city regions it could make a difference. I have verified that for the GB map, those roads that cause a Table B to be larger than the previous limit are routable as normal. Anyway, please test if you can and as long as it doesn't introduce any problems it's worth incorporating this. Mark

2 8

[PATCH] Display traffic_calming=* as natural=rock
by Marko Mäkelä 25 Nov '09

25 Nov '09

The attached patch translates traffic_calming=* (speed bumps, humps etc.) into 0x6614 at zoom levels of 200m and closer. The Edge 705 displays them as white small circles. Best regards, Marko

1 0

Restriction relation problems
by Andrew McCarthy 25 Nov '09

25 Nov '09

Hi folks, I'm having trouble with turn restriction relations, but can't figure out why. I've enabled logging (info-level) and can see some restrictions being created, such as this one: http://www.openstreetmap.org/browse/relation/36150 2009/11/23 20:44:17 INFO (RestrictionRelation): Turn restriction http://www.openstreetmap.org/browse/relation/36150 (at http://www.openstreetmap.org/?lat=53.33131&lon=-6.24412&zoom=17) no_right_turn added - blocks routing to way 7988564 However, other restrictions, such as this one, which is virtually identical in form, doesn't show up in the logs at all and is definitely not obeyed by my Garmin: http://www.openstreetmap.org/browse/relation/65792 Are there any known issues with reading relations, or does anyone have suggestions how to figure what's happening with relations like the second one? Thanks! Andrew

2 7

Turn restrictions in foot mode
by Chris-Hein Lunkhusen 25 Nov '09

25 Nov '09

Hi, I tested some turn restrictions in Mapsource and found that they are used in all modes (car/bicycle/foot). Is there an option to disable them for foot ? In Germany the traffic signs for T.R. are only valid for vehicles. Chris

4 4

Broken coastline errors between V1188 and V1398
by Michael.TheBlackCat 25 Nov '09

25 Nov '09

dear developers, i recognized broken coastline errors between the mkgmap verion 1188 and 1398. Please refer to the appended jpegs (my coastline is a little bit thicker ti identify the sea area). Here is the original osm position: http://www.openstreetmap.org/?lat=54.562&lon=9.983&zoom=11&layers=B000FTF You can download all the data from my server: a) version 1188: http://planetearth.informatik.haw-hamburg.de/forMapSource/schleswig-holstei… b) version 1398: http://planetearth.informatik.haw-hamburg.de/error_mkgmap-r1398_forMapSourc… c) the build script: http://planetearth.informatik.haw-hamburg.de/scripte/doSchleswigHolstein.ba… d) the build script: http://planetearth.informatik.haw-hamburg.de/error_mkgmap-r1398_forSDcard/s… It seems, that the error belongs to changes (see last jpeg) in multipolygon behavior of newer mkgmap code. Please check, whether there is a new problem in the code or in the tags from the maps. regards Michael

2 5

Route calculation error introduced in r1337:1343
by Marko Mäkelä 24 Nov '09

24 Nov '09

Hi Mark, About a week ago, I began experiencing route calculation errors on the Edge 705. I cannot calculate a bicycle or walking route from my home (2 km east from the Korso railway stop) to the Pasila railway station or the center of Helsinki (a few km further south). Because a Nüvi user complained about broken car routing west from Helsinki, with no obvious error in the OSM data, I decided to test earlier versions of mkgmap. Dropping the option --adjust-turn-headings did not make any difference. I just rebuilt and tested the following mkgmap revisions: r1319: ok r1331: ok r1337: ok r1343: route calculation error In addition to these, I have built (broken) maps with r1344, r1362, and r1364. Should I track down the earliest buggy revision, or is the r1337:1343 range of revisions specific enough? Best regards, Marko

2 8

access=no on a cycleway doesn't work?
by Federico Cozzi 24 Nov '09

24 Nov '09

Hello, I am not subscribed to the list but I read an interesting message by Marko Mäkelä in the archive which I quote here: -------------------- > In my neighbourhood there's a highway=cycleway that is currently blocked > due to construction works. As the cycleway is still there (the cycleway > itself is not under construction), I tagged it access=no. However, > mkgmap still tries to route me over it. > Is that because styles file saying: "highway=cycleway {add access = no; > add bicycle = yes;" ? Or just use the "native" tags, but explicitly translate "access" to the vehicle-class tags and do not treat "access" specially in the core, e.g., access=no { add bicycle=no; add foot=no; add motorcar=no; add taxi=no; ... } -------------------- I do not know how mkgmap internally works, but I think that "access" should not even belong to the core! As far as I know Garmin maps only handle a fixed number of vehicle classes (e.g. motorcar, taxi, bicycle, etc.), not a general purpose catch-all vehicle class. Therefore the style file should say: access = no {add motorcar = no; add taxi = no; add bicycle = no; ...} highway = cycleway {add motorcar=no; add taxi=no; add bicycle = yes; ...} This way, a standard highway=cycleway with no additional tags would get bicycle=yes (and everything else = no); a highway=cycleway with access=no would get bicycle = no (and also everything else = no) Bye, Federico

5 11

Commit: r1404: Fixed bug that broke turn restrictions if via node was also a POI.
by svn commit 24 Nov '09

24 Nov '09

Version 1404 was commited by markb on 2009-11-24 00:15:11 +0000 (Tue, 24 Nov 2009) Fixed bug that broke turn restrictions if via node was also a POI. If a node was both a POI and the "via" node of a turn restriction, using the link-pois-to-ways option to make the POI's tags accessible when processing the way, broke the turn restriction processing because it did not replace the POI's Node object when the Coord was swapped out for a CoordPOI and so the Node continued to hold a reference to the original Coord and not the CoordPOI. The turn restrictions went on to use the original Coord from the original Node and as its identity didn't match the CoordPOI, the restrictions got skipped. No more.

1 0