February 2009 - mkgmap-dev - The mkgmap lists

OT - Access/Turn Restrictions
by Paul 01 Mar '09

01 Mar '09

I have the situation below where road C is pedestrianised except for buses between 0800 and 1800 and is accessible by everything at other times. I've currently got it covered by no_left_turn restrictions from A or E to C and no_straight_on from B or D to C but this doesn't fully describe the restrictions (these have hour_on/off parameters). My question is how would I fully describe this situation with turn or access restrictions? |A | | B------@-------C---------@---D--- | |E Cheers Paul

4 5

Preservation of order not working
by Nop 01 Mar '09

01 Mar '09

Hello! My application makes heavy use of a layering concept that puts items in a particular order so they are drawn on top of each other on the garmin. This is used to draw bridges/tunnels in the proper order and to construct composite elements by overlaying multiple lines or icons in a particular order. Versions of mkgamp up to 590 did maintain the order of elements, in later versions the order was random due to use of a hash map, then maintaining the order was restored - theoretically. I now tried to migrate my application to work with current versions of mkgmap, but the drawing order still does not correspond to the order in the input osm file. In the particular use case I attempt to create markings for hiking trails by drawing a symbol (e.g. yellow cross) on top of a background (white rectangle). I double-checked the OSM input file, all the background nodes are in the file before any of the symbol nodes. In the output, the symbols are drawn correctly on top or hidden behind the white rectangles at random. The effect is the same in MapSource and on the device. The same symbol/background combinations are sometimes drawn properly and sometimes in reverse order. I have attached two images showing the good and broken case on two neighboring nodes. From the tooltips in Mapsource you can see the inverted order of foreground and background in the broken case. I have checked this with mkgmap r858 and r935, both with identical results. The last version this works completely is r590. Ways seem to be ok, at least I could see no problems there during my first tests. Is it possible that the fix only applies to ways but not tod nodes? bye Nop

4 12

Commit: r951: Merge fix for iteration over tags.
by svn commit 28 Feb '09

28 Feb '09

Version 951 was commited by steve on 2009-02-28 23:38:46 +0000 (Sat, 28 Feb 2009) Merge fix for iteration over tags.

1 0

Commit: r950: Add blurb for --preserve-element-order.
by svn commit 28 Feb '09

28 Feb '09

Version 950 was commited by markb on 2009-02-28 23:27:43 +0000 (Sat, 28 Feb 2009) Add blurb for --preserve-element-order.

1 0

Tile size and routing performance?
by Mark Burton 28 Feb '09

28 Feb '09

Just a thought. When I split the map I am using for testing, I specify --max-nodes=100000 to the splitter. This is quite a lot smaller than the default value for max-nodes. Those of you suffering inter-tile routing problems, what value are you using for max-nodes? If you're using the default value, why not try using a smaller value and see if it makes any difference to the routing performance? Cheers, Mark

2 1

Commit: r949: A patch to, optionally, preserve the element ordering.
by svn commit 28 Feb '09

28 Feb '09

Version 949 was commited by steve on 2009-02-28 23:15:22 +0000 (Sat, 28 Feb 2009) A patch to, optionally, preserve the element ordering. - Mark Burton

1 0

Commit: r948: POI version 6
by svn commit 28 Feb '09

28 Feb '09

Version 948 was commited by steve on 2009-02-28 22:37:48 +0000 (Sat, 28 Feb 2009) BRANCH: poi POI version 6 - Poi address information is now added by default -- Option -no-poi-address added to switch the feature off - Check if zip tag contains a list of zips added - By default heuristic is disabled. Exception are: -- Name of nearest city is added to street POIs (if street POIs are enabled) -- If POI contains a city name tag. Country region info is taken from city with same name in the neighborhood - You can use the --location-autofill=X option to enable heuristic if you like - Bernhard Heibler

1 0

Commit: r947: Found reason that tag adding failed in real use.
by svn commit 28 Feb '09

28 Feb '09

Version 947 was commited by steve on 2009-02-28 18:59:24 +0000 (Sat, 28 Feb 2009) BRANCH: tags-bug Found reason that tag adding failed in real use. Test changed to reflect that and tags iteration code fixed.

1 0

Who's to blame when the route offered is sub-optimal?
by Mark Burton 28 Feb '09

28 Feb '09

I am coming to the conclusion that the garmin routing engine has some definite limits as to what it can do in terms of route quality. Tweaking the road class/speed parameters can make a difference but the real solution to achieving a really good route is to take pity on the gps and put in a few strategic way points. Given some hints, I think it does OK. I feel that it's just too much to expect of the gps to be able to route long distances optimally without a bit of help from the human. I'm not saying that the current implementation of routing support cannot be improved, I am sure that it can. But even if our code was perfect, the routing is still going to be influenced by the quality of garmin's routing engine and, crucially, the quality of the OSM data. Cheers, Mark

2 1

Commit: r946: Fix multiple tags and multiple iterations.
by svn commit 28 Feb '09

28 Feb '09

Version 946 was commited by steve on 2009-02-28 15:07:31 +0000 (Sat, 28 Feb 2009) BRANCH: tags-bug Fix multiple tags and multiple iterations. In the normal case with many tags added, this should decrease memory usage too.

1 0