October 2013 - mkgmap-dev - The mkgmap lists

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

mergeroads - Handling of mkgmap:carpool
by WanMil 12 Oct '13

12 Oct '13

I've changed how the mkgmap:carpool flag is handled. It is no longer handled as common access flag, which means the new actions add/setaccess no longer set the mkgmap:carpool flag. There was a problem with such a rule: access=yes { setaccess yes } It classified the road as carpool which means it can only be used for carpools, emergencies and busses... This is the handling now: The no carpool bit (0x0008 see RoadDef) is set except mkgmap:carpool is set to yes. (In this case all other mkgmap:xxx access flags are set to no - except emergency and bus which are set to yes). @All: Is the carpool bit handled correctly? How can I test? Shall the extra handling (automatic setting of all other mkgmap:xxx access flags) should still be used? I think this could better be done by the style developer? Example: carpool=yes { set mkgmap:carpool=yes; setaccess no; set mkgmap:emergency=yes } @Programmers: Shall we remove the carpool bit from the common access flags and add a separate method setCarpool(boolean) to the RoadDef class like it is done with the throughroute, unpaved etc. flags? I find it quite irritating to have carpool in the common access bits. WanMil

3 2

Problem with compiling TYP containing Cyrillic characters (mkgmap r2673)
by keenonkites 10 Oct '13

10 Oct '13

Gents, I have a properly translated source Text file (UTF-8 with BOM) for Russian containing, obviously, cyrillic characters. It contains definitions like (for example): [_line] Type=0x10103 UseOrientation=Y LineWidth=2 Xpm="0 0 1 0" "1 c #99CCCC" String1=0x19,?????/??? ExtendedLabels=Y FontStyle=NoLabel (invisible) CustomColor=No [end] Complete file can be downloaded at https://dl.dropboxusercontent.com/u/40846569/freizeit.zip Unfortunately mkgmap doesn't like it and fails to compile such a text file into a binary TYP file: java -Xmx1536M -jar P:/Freizeitkarte/develop/fzk-mde-garmin.git/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar --max-jobs=2 --code-page=1251 --product-id=1 --family-id=6442 freizeit.txt Time started: Tue Oct 08 11:30:55 CEST 2013 java.lang.NullPointerException: charsetName at java.io.InputStreamReader.<init>(Unknown Source) at uk.me.parabola.mkgmap.main.TypCompiler.compile(TypCompiler.java:123) at uk.me.parabola.mkgmap.main.TypCompiler.makeMap(TypCompiler.java:70) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:243) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:239) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option Time finished: Tue Oct 08 11:30:55 CEST 2013 Total time taken: 176ms Exact the same happens if I try to compile it with the option --code-page=65001 (for unicode). Any clue ? is this an enduser problem or a mkgmap problem ? Thanks for the help. Patrik

2 14