March 2017 - mkgmap-dev - The mkgmap lists

Directionality of stop signs
by Dave Swarthout 23 Mar '17

23 Mar '17

There is an ongoing discussion on the Tagging list that is trying to determine how to tag the directionality of stop signs and yield signs as well as traffic_signals. The arguments is that if a highway=stop is placed on a node that is at the intersection of two ways, it applies to all vehicles crossing that node. However, if the stop sign applies to only one of the ways at an intersection, the highway=stop node must appear on the proper way at a slight distance from the actual intersection. How does a routing engine determine whether it's approaching from the "front" of the sign, in which case a stop penalty should be calculated, or from the other direction, in which case the sign can be ignored? Does anybody know whether the Garmin routing algo even considers stop signs? Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

2 1

Performance with large files
by Bernhard Hiller 22 Mar '17

22 Mar '17

How is mkgmap expected to behave when input files grow in size? Is a linear inrease in calculation time - i.e. O(n) - expected, or an increase beyond linearity? E.g. when I create a map with routable lines for bicycle, mkgmap takes some 30 minutes for Germany alone (3 GB pbf file resulting in 850 MB img file), but more than 2 hours for Germany and some neighboring countries (7 GB o5m file, resulting 1.4 GB img). Are there many calculations at O(n^2) or beyond in mkgmap, or is this due to other factors, e.g. memory limitation? Notes: mkgmap is called by %JAVA% -Xmx6800M -ea -jar %MKGMAP% .... on 64bit Win 7; swapping to disc does not occur. But I am more interested in a general rule than in some hints for improving the performance in this concrete case. E.g. how I could estimate the duration if I add some further countries... Thanks for your hints.

2 11

Do we need address data for sea polygons ?
by Gerd Petermann 22 Mar '17

22 Mar '17

Hi all, my recent changes in r3861 and r3862 have a side effect: Before these changes mkgmap always added the address tags (mkgmap:admin_level2 .. 11 and mkgmap:postcode) to the polygons generated by the SeaGenerator. With the latest changes this might not happen for some polygons, depending on the distribution of the nodes. Now I wonder if we ever needed the address information in those polygons. I don't yet see a reason to do that, so maybe the LocationHook can ignore all polygons created by SeaGenerator? Gerd

1 0

Commit r3862: fix problem introduced with r3861: handle special case when input file contains no data
by svn commit 22 Mar '17

22 Mar '17

Version mkgmap-r3862 was committed by gerd on Wed, 22 Mar 2017 fix problem introduced with r3861: handle special case when input file contains no data Don't try to use invalid bbox. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3862

1 0

Commit r3861: improve performance of LocationHook when input file bounds data is huge.
by svn commit 22 Mar '17

22 Mar '17

Version mkgmap-r3861 was committed by gerd on Wed, 22 Mar 2017 improve performance of LocationHook when input file bounds data is huge. Calculate the intersection of the bounds and the bounding box of all nodes instead of using the bounds directly. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3861

2 1

Commit r3860: correction for new option --ignore-fixme-values: don't remove the tags fixme or FIXME if they have the value like fixme
by svn commit 21 Mar '17

21 Mar '17

Version mkgmap-r3860 was committed by gerd on Tue, 21 Mar 2017 correction for new option --ignore-fixme-values: don't remove the tags fixme or FIXME if they have the value like fixme http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3860

3 3

Commit r3859: Implement new option --ignore-fixme-values to ignore tags with values that contain the fixme pattern. If one uses the option he can disable the corresponding rules
by svn commit 21 Mar '17

21 Mar '17

Version mkgmap-r3859 was committed by gerd on Tue, 21 Mar 2017 Implement new option --ignore-fixme-values to ignore tags with values that contain the fixme pattern. If one uses the option he can disable the corresponding rules in inc/name. --ignore-fixme-values Tells mkgmap to ignore all tags for which the value matches the pattern "(?i)fix[ _]?+me". http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3859

1 0

Commit r3858: refactoring: method idVal(String) is only used for XML reader
by svn commit 21 Mar '17

21 Mar '17

Version mkgmap-r3858 was committed by gerd on Tue, 21 Mar 2017 refactoring: method idVal(String) is only used for XML reader http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3858

1 0

fixme rules
by Andrzej Popowski 21 Mar '17

21 Mar '17

Hi, there are some rules in include/name, designed to remove "fixme" value from tags. Unfortunately they are executed too late for many cases, for example for highway "name" and "ref". I propose to add a file include/fixme to default style and include it at the beginning of points, lines and polygon files. This file could contain fixme rules and other rules, that are useful for all objects. I have found these functions useful: - fixme rules - setting mkgmap:country tag, - correction for multipolygon without area=yes - forcing finalize stage for address I have attached proposed patch to this mail. It duplicate some rules from other includes, which could be removed there, but I haven't done it yet. -- Best regards, Andrzej

6 11

Commit r3857: - refactoring to improve readability of code for high precision
by svn commit 21 Mar '17

21 Mar '17

Version mkgmap-r3857 was committed by gerd on Tue, 21 Mar 2017 - refactoring to improve readability of code for high precision - add TODO for 32 bit high prec based on modified diff_coord_v3.patch http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3857

1 0