January 2014 - mkgmap-dev - The mkgmap lists

Commit: r2943: Change algorithm in RoadMerger that it preserves a stable order. Also fix the junit tests.
by svn commit 05 Jan '14

05 Jan '14

Version mkgmap-r2943 was committed by wanmil on Sun, 05 Jan 2014 Change algorithm in RoadMerger that it preserves a stable order. Also fix the junit tests.

1 0

Immer noch Zufall drin
by Gerd Petermann 04 Jan '14

04 Jan '14

Hi WanMil, ich weiss nicht warum, aber bei grösseren Datenmengen sehe ich immer noch verschiedene Ergebnisse. Das Problem verschwindet, wenn man die Liste auch noch (nach lon+lat) sortiert. Ich denke, das sollte nicht so sein. Meine Vermutung: Irgendwas geht beim Mergen schief, so das bereits "gemergete" Wege anders behandelt werden. Ich forsche noch... Ich verwende übrigens die Vergleichsfunktion vom Totalcommander: http://www.ghisler.com/ (Siehe Screenshot) Da reichen ein paar Tastendrücke, und man sieht unten links "6 Unterschiede gefunden" wenn alles passt, sonst eher "39122 Unterschiede gefunden" Ciao, Gerd

2 1

Commit: r2941: Skip restriction relations that have no restriction=* tag.
by svn commit 04 Jan '14

04 Jan '14

Version mkgmap-r2941 was committed by marko on Sat, 04 Jan 2014 Skip restriction relations that have no restriction=* tag.

1 0

Commit: r2939: RoadMerger now preservers the original order of roads
by svn commit 04 Jan '14

04 Jan '14

Version mkgmap-r2939 was committed by wanmil on Sat, 04 Jan 2014 RoadMerger now preservers the original order of roads This is done by keeping the index of roads and sorting it by this index after merging.

1 0

Commit: r2938: RoadMerger always checks Coords for identity and not using equals() method
by svn commit 04 Jan '14

04 Jan '14

Version mkgmap-r2938 was committed by wanmil on Sat, 04 Jan 2014 RoadMerger always checks Coords for identity and not using equals() method

1 0

Commit: r2934: Change internal handling of the carpool flag
by svn commit 03 Jan '14

03 Jan '14

Version mkgmap-r2934 was committed by wanmil on Fri, 03 Jan 2014 Change internal handling of the carpool flag It is now separated from the access flags array. The change should not change anything in the map. It's an internal implementation change only.

1 0

Commit: r2932: - added check for invalid types in style files.
by svn commit 03 Jan '14

03 Jan '14

Version mkgmap-r2932 was committed by gerd on Fri, 03 Jan 2014 - added check for invalid types in style files. Execution stops when a wrong type is found and the style is not read by the --check-style option. - allow writing 0xYY00 instead of 0xYY in lines and polygons file

2 1

Commit: r2933: - change unit tests to use only allowed types
by svn commit 03 Jan '14

03 Jan '14

Version mkgmap-r2933 was committed by gerd on Fri, 03 Jan 2014 - change unit tests to use only allowed types - don't allow 0xYY00 for lines, only for polygons - allow any type for lines when overlays are available

1 0

invalid types in check-styles
by nwillink 03 Jan '14

03 Jan '14

Hi Interesting 'bug' when using check-styles. It had me foxed as it actually by chance highlighted lines I didn't use in my TYP file. invalid type 0x11f for POLYLINE It transpires that when replacing 11f with 11f00 the type number is correctly identified as valid. I checked it with several lines, with and without the zero subtypes. -- View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 9

routing seems to depend on order of ways
by Gerd Petermann 03 Jan '14

03 Jan '14

Hi Steve, I think I found a very old bug in mkgmap, it seems to exist since at least r2210. I found it while testing a patch for r2914 and found it in all older versions that I tried. Attached are two test files and a gdb for MapSource. The command that I use: java -jar d:\mkgmap\dist\mkgmap_r2889.jar --link-pois-to-ways --route --nsis --tdbfile --preserve-element-order f:\osm\good.osm or java -jar d:\mkgmap\dist\mkgmap_r2889.jar --link-pois-to-ways --route --nsis --tdbfile --preserve-element-order f:\osm\bad.osm The only difference in the two files is the order of the ways w3 and w4 (the ids don't seem to matter) I use r2889 to test this because current trunk version uses a sort in the RoadMerger, but the error is not related to the merge. With bad.osm MapSource calculates a route that that passes the target point, goes up to the barrier and then reverses back to the target. This happens with vehicles like car and bike and seems not to be related to any routing preferences. I hope you can reproduce the problem and find out what goes wrong... Gerd

4 5