March 2017 - mkgmap-dev - The mkgmap lists

[Patch v1] differet Coord implementation
by Gerd Petermann 14 Mar '17

14 Mar '17

Hi programmers, After writing my findings here http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026317.html I did some cycling and decided that I might still be better to use the attached patch. It works better with 32 bits and is probably a bit easier to understand. The major difference is that it calculates the Garmin position of a point from the already rounded 30 (or 32 bit) value. In some cases this means that points in the map move by one, e.g. one with 52.2452629, 21.0833536 appears on the right grid point instead of the left (it is very close to the middle). Gerd

3 3

Overview map
by Mike Baggaley 14 Mar '17

14 Mar '17

Gerd's comment about looking at the overview map, prompted me to look at mine, and I realised I didn't have one (or it is empty), despite me having --tdbfile specified - the help for this option says an overview map will be created. I assume I am not getting an overview map because I don't have --overview-levels specified. Would it be better if the default for --overview-levels is not an empty string when --tdbfile is specified? The documentation for --overview-levels is not very clear. From inspecting the code it looks like the format expected is similar to the format expected by --levels and that the overview level numbers should be greater than the normal levels. Can the documentation for this be improved? Also, what is the benefit of specifying something like --overview-levels=5:15,6:13,7:11 over the much simpler --overview-levels=15,13,11 and have mkgmap work out the next free levels. Could we simplify this? Regards, Mike

2 3

generate-sea: behaviour
by Ticker Berkin 14 Mar '17

14 Mar '17

Hi I've been using --generate-sea rather than --precomp-sea for a few weeks and there doesn't seem to be an obvious performance penalty and the img size is slightly better (but I have been changing other things along the way). However - It doesn't seem to know about the rule that land must be on the left of the coastline and sea on the right. Taking the geofabrik download of UK/Hampshire, the Isle of Wight is (correctly) mostly excluded - just 3 bits of coastline that don't meet each other or the bottom edge of the tile. With --generate-sea=multipolygon, I sometimes get the top half, which is correctly defined land, ie has coastline to the tile edge, as sea and the sea as nothing. The bits of disconnected coastline sometimes have a triangle of sea where it should be, sometimes where the land is! With extend-sea-sectors,gap=350 it is much better behaved. Maybe the default behaviour should be to ignore these disconnected bits of coastline (with a warning), hence both sides will show as sea. The coast of the requested area should behave correctly. Ticker

2 1

x-residential-hook missing tile
by Arndt Röhrig 13 Mar '17

13 Mar '17

2 3

Commit r3846: prevent another possible ArrayIndexOutOfBoundsException in BoundaryLocationPreparer
by svn commit 13 Mar '17

13 Mar '17

Version mkgmap-r3846 was committed by gerd on Mon, 13 Mar 2017 prevent another possible ArrayIndexOutOfBoundsException in BoundaryLocationPreparer tag value may contain a single comma http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3846

1 0

Commit r3845: prevent possible ArrayIndexOutOfBoundsException in BoundaryLocationPreparer
by svn commit 13 Mar '17

13 Mar '17

Version mkgmap-r3845 was committed by gerd on Mon, 13 Mar 2017 prevent possible ArrayIndexOutOfBoundsException in BoundaryLocationPreparer tag value may be an empty string after style processing http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3845

1 0

Commit r3844: Improve (again) throughput and efficiency of ShapeMergeFilter
by svn commit 13 Mar '17

13 Mar '17

Version mkgmap-r3844 was committed by gerd on Mon, 13 Mar 2017 Improve (again) throughput and efficiency of ShapeMergeFilter - Much faster for tiles with lots of islands (--precomp-sea) - Finds a few more merges Map for Finland needed 200s with r3843, is now done in 120s http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3844

1 0

Commit r3843: Improve throughput and efficiency of ShapeMergeFilter
by svn commit 13 Mar '17

13 Mar '17

Version mkgmap-r3843 was committed by gerd on Mon, 13 Mar 2017 Improve throughput and efficiency of ShapeMergeFilter - Much faster for tiles with lots of islands (--precomp-sea) - Finds a few more possible merges http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3843

2 1

Splitter multiple input files
by Mike Baggaley 12 Mar '17

12 Mar '17

Quick question - can splitter accept multiple input files? I'm currently using osmconvert to merge data into a single file before passing to splitter, but wondered whether I am unnecessarily doing this merge. Thanks, Mike

2 1

Commit r3841: simplify and correct code for precompiled boundaries
by svn commit 11 Mar '17

11 Mar '17

Version mkgmap-r3841 was committed by gerd on Sat, 11 Mar 2017 simplify and correct code for precompiled boundaries Don't reject a valid postal_code boundary if it its also an invalid or incomplete administrative boundary. The old code rejected boundaries if they only contained these tags: postal_code=1234, boundary=administrative (admin_level + name missing) or postal_code=1234, boundary=administrative,admin_level=12,name=Bahnhofsvierten ("invalid" admin_level) Expected effect: Precompiled bounds may be a bit larger, mkgmap:postcode should be filled for elements in areas previously rejected http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3841

1 0