- mkgmap-dev - The mkgmap lists

Commit r3866: code cleanup: remove undocumented partial implementation of option contours (SRTM data).
by svn commit 25 Mar '17

25 Mar '17

Version mkgmap-r3866 was committed by gerd on Sat, 25 Mar 2017 code cleanup: remove undocumented partial implementation of option contours (SRTM data). The code is not fully working and may cause "There is not enough room in a single garmin map for all the input data." errors as it is difficult to predict the numer of elements added from SRTM data. The combination of tools like phyghtmap or srtm2osm in combination with splitter is the better choice. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3866

1 0

Commit r3865: code cleanup, no functional change: Create OverviewMapDataSource instance in OverviewBuilder instead of Main
by svn commit 25 Mar '17

25 Mar '17

Version mkgmap-r3865 was committed by gerd on Sat, 25 Mar 2017 code cleanup, no functional change: Create OverviewMapDataSource instance in OverviewBuilder instead of Main http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3865

1 0

Commit r3864: refactoring, no functional change: rewrite code which was intended to implement a plugin system for OSM readers
by svn commit 24 Mar '17

24 Mar '17

Version mkgmap-r3864 was committed by gerd on Fri, 24 Mar 2017 refactoring, no functional change: rewrite code which was intended to implement a plugin system for OSM readers This makes the code more transparent. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3864

1 0

Commit r3863: code cleanup, no functional change
by svn commit 23 Mar '17

23 Mar '17

Version mkgmap-r3863 was committed by gerd on Thu, 23 Mar 2017 code cleanup, no functional change - Don't create anonymous classes to initialize static Collections - calculate all used tags in method getUsedTags() in HighwayHooks instead of mixing static and dynamic code http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3863

1 0

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