- mkgmap-dev - The mkgmap lists

Commit: r2758: Create valid map when --route is used with level 0
by svn commit 15 Oct '13

15 Oct '13

Version 2758 was committed by gerd on Tue, 15 Oct 2013 Create valid map when --route is used with level 0 having resolution < 24. Check for level==0 instead of resolution==24.

1 0

unit tests
by GerdP 15 Oct '13

15 Oct '13

Hi Steve, the unit tests in SimpleTest and SimpleRouteTest stop on the first failure. Therefore one has to adapt one value, repeat all tests, adapt next value, and so on. I'd prefer to see all changes in one go. Is that possible? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/unit-tests-tp5781582.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

short arcs demystified, please try value 0
by GerdP 15 Oct '13

15 Oct '13

Hi all, I think I understand now most of the miracles related to short arcs and I am pretty sure that we can solve the known problems without adding source complexity. 1) In 2009 Mark Burton added the remove-short-arcs option with r1049. 2) With r1060 he added the option to pass a parameter giving the minimum arc length to fix problems like "disappearing ways". Unfortunately, he missed the real reason for the error, which IMHO was the buggy implementation of --link-pois-to-ways and --remove-short-arcs regarding the highway count causing more or less unpredictable results. 3) For four years people wondered what value to use as a change of the value was likely to "fix" a known routing error while also adding other "not yet known" errors. Today I've committed r2736. I my eyes (presuming all coding errors are fixed now) the only usable value is --remove-short-arcs=0, everything else is likely to create problems like distorted lines, wrong routing (cars routed through footways) and wrong exit hints in roundabouts. The only advantage that I see is a slightly smaller number of nodes, but this will soon be fixed when the mergeroads branch is merged to trunk, but I might have missed something. So, in short: All those that are using mkgmap to create routable maps, please try r2736 with --remove-short-arcs=0 (binary is here http://files.mkgmap.org.uk/download/152/mkgmap.jar) or use the mergeroads branch (requires style changes) If you find any problem regarding routing, please let us know and try to provide details. If I hear no complains until Oct 15, I like to change the default back to 0 and print a warning if a different value is used. If --remove-short-arcs=0 works fine for everybody, we should remove the option. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/short-arcs-demystified-please-try-value-0-tp… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 8

Commit: r2757: change default value of remove-short-arcs option to 0.
by svn commit 15 Oct '13

15 Oct '13

Version 2757 was committed by gerd on Tue, 15 Oct 2013 change default value of remove-short-arcs option to 0. Print warning to stderr if a value > 0 is used.

1 0

mkgmap-mergeroads
by Minko 13 Oct '13

13 Oct '13

Hi, I've noticed the bicycle routing in the mkgmap-mergeroads branch completely ignores bicycle=no, routing takes motorways and other roads tagged with bicycle=no. Tested it with mkgmap-mergeroads-r2750 with the built in style and in Mapsource: bicycle mode, way selection in the middle, shorter distance. Wanmil, I have no clue how to fix this in the styles, can you have a look at this? My Mkgmap args are: name-tag-list: name,int_name,name:en,name:nl,name:de,name:fr,place_name generate-sea: land-tag=natural=background precomp-sea: G:\mkgmap\Sea\sea_20130814.zip bounds: G:\mkgmap\Boundaries\bounds_20130814.zip location-autofill: is-in,nearest housenumbers tdbfile latin1 code-page: 1252 show-profiles: 1 #ignore-maxspeeds remove-short-arcs min-size-polygon: 4 polygon-size-limits=17:2, 15:0 merge-lines add-pois-to-areas add-pois-to-lines preserve-element-order keep-going net route index nsis

5 27

man_made structures in the polygon style
by Minko 13 Oct '13

13 Oct '13

Hi, Can man_made=pier and man_made=bridge added to # squares and plazas highway=pedestrian & area=yes [0x17 resolution 22] man_made=pier | man_made=bridge [0x17 resolution 22] And man_made=groyne and man_made=reinforced_slope (same thing as breakwater, used frequently in NL) are rendered as building in the default style, which is not good Solution: # man_made can be used on areas or lines man_made=* & area!=no & (man_made!=door & man_made!=embankment & man_made!=breakwater & man_made!=cable_line & man_made!=cutline & man_made!=cutting & man_made!=groyne & man_made!=levee & man_made!=reinforced_slope & man_made!=trench) [0x13 resolution 24]

2 2

Commit: r2754: Partly revert the merge-lines-v2.patch: don't merge roads, this causes
by svn commit 12 Oct '13

12 Oct '13

Version 2754 was committed by gerd on Sat, 12 Oct 2013 Partly revert the merge-lines-v2.patch: don't merge roads, this causes wrong NET data and wrong placement of cursor in MapSource when pointing on a road in lower resolutions.

1 0

[Patch v1] allow --route with highest resolution < 24
by Gerd Petermann 12 Oct '13

12 Oct '13

Hi, the attached small patch allows to create a routable map with level 0 not being at resolution 24. I did not test routing very much, but at least MapSource doesn't crash. A compiled binary based on r2478 is here: http://files.mkgmap.org.uk/download/158/mkgmap.jar Gerd

3 5

version 2718 and construction {name '${name} text'|'text'} not work
by Maks Vasilev 12 Oct '13

12 Oct '13

I have in point file rules: shop=kiosk {name '${name}, киоск'|'киоск'} [0x2e02 resolution 20] On old version mkgmap point set name as "Name, киоск" if poi have name=Name or name as "киоск" if poi without name tag. Now in 2718 poi have only name as "Name" or name as "киоск". It's a bug or new mkgmap used new syntax for text manipulation?

2 8

[Patch v1] Don't write useless data to NET file
by GerdP 12 Oct '13

12 Oct '13

Hi, I think mkgmap writes too much data to the NET file, or some of it is probably wrong. Since r2586 we "use merge-lines for all lines in all resolutions, except for roads in res 24" In MapBuilder.LineAddFilter we have code that checks whether a line is a road, if yes, the MapLine is added to the corresponding RoadDef instance and later it is written to the NET file. We do this for all resolutions, no matter wheter the road was merged with other lines or not. I wondered why this did not cause trouble, as a RoadDef instance now may point to very different polylines at the different resolutions. I changed the code so that we only add the line to the RoadDef in resolution 24. See attached patch. reduce_net_v1.patch <http://gis.19327.n5.nabble.com/file/n5781077/reduce_net_v1.patch> I did not see any change in MapSource, routing etc. seems to work as before, but the img file size was reduced from ~140Mb to ~130MB. Compiled binary based on trunk version r2748 is here: http://files.mkgmap.org.uk/download/157/mkgmap.jar @Steve: I assume that the Garmin maps contain also data for lower resolutions in NET, so maybe they also have NOD data that points to this while we have not? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v1-Don-t-write-useless-data-to-NET-fil… Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 8