- mkgmap-dev - The mkgmap lists

Commit: r954: Merged from trunk.
by svn commit 01 Mar '09

01 Mar '09

Version 954 was commited by steve on 2009-03-01 16:30:45 +0000 (Sun, 01 Mar 2009) BRANCH: poi Merged from trunk. Test values changed to match different lable section size. Please test this well.

2 1

Commit: r953: Create POIs inside areas if they do not already have one.
by svn commit 01 Mar '09

01 Mar '09

Version 953 was commited by steve on 2009-03-01 00:18:42 +0000 (Sun, 01 Mar 2009) BRANCH: poi Create POIs inside areas if they do not already have one. Bernhard Heibler: I have integrated Ben Konrath's Area POI patch into my code. I did the following changes to Ben's code: - Replaced the hard coded area to poi type mapping with the build in rule sets. Shapes are checked against the point rules to add missing pois. - Replaced the linear search (to avoid duplicated pois) with tile based search - Add buildings to polygons style - Moved my helper classes to general directory You have to add the --add-pois-to-areas to enable the Area POIs generation. I'm not sure if we should generate a new rule set in the style folder for this purpose. It works pretty good using the point rules but it might be confusing. - Original patch by Ben Konrath, itegrated by Bernhard Heibler

3 2

Commit: r952: Run test with preserve-element-order as otherwise you
by svn commit 01 Mar '09

01 Mar '09

Version 952 was commited by steve on 2009-03-01 00:17:31 +0000 (Sun, 01 Mar 2009) Run test with preserve-element-order as otherwise you get a different result with java5 and java6.

1 0

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