April 2020 - mkgmap-dev - The mkgmap lists

Commit r4483: fix documentation for --licence-file reg. underscores
by svn commit 19 Apr '20

19 Apr '20

Version mkgmap-r4483 was committed by gerd on Sun, 19 Apr 2020 fix documentation for --licence-file reg. underscores $LONG_DATE$ -> $LONGDATE$, $SHORT_DATE$ -> $SHORTDATE$ http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4483

1 0

License File <mapid>000_license.txt
by Mike Baggaley 16 Apr '20

16 Apr '20

Hi all, I notice that mkgmap creates a file named <mapid>000_license.txt that contains the following text: Map data (c) OpenStreetMap and its contributors http://www.openstreetmap.org/copyright This map data is made available under the Open Database License: http://opendatacommons.org/licenses/odbl/1.0/. Any rights in individual contents of the database are licensed under the Database Contents License: http://opendatacommons.org/licenses/dbcl/1.0/ Map created with mkgmap-r4473M This does not seem to be displayable in either Basecamp or Mapsource and does not contain the txt from my --license-file option. Can anyone explain what this file is for and whether there is a registry setting to get Basecamp/Mapsource to display it? Also whether there is a reason it does not contain the text from the --license-file option? Cheers, Mike

1 0

POI barrier/access restriction
by Ticker Berkin 15 Apr '20

15 Apr '20

Hi Gerd and others interested in routing issues default style "points" has code that, when option --link-pois-to-ways is in effect, sets highway access and speed restrictions that mkgmap then imposes on the highway that the point is on. These rules had various errors: - didn't expand the access mode hierarchy, see https://wiki.openstreetmap.org/wiki/Key:access - tested the wrong tag for mkgmap:bus and mkgmap:delivery - if the "access" tag was set, apply this to all modes before processing allowances and restrictions imposed by the barrier; but these actions would have no effect because the the specified mode tags are now all set - assumed that a gate stops motor_vehicle access - didn't handle other common forms of gate - allowed bicycle through kissing_gate and stile This patch fixes these problems and also adds a speed restriction for all barriers. The general principle is that barrier rules add specific "no" restrictions that the barrier prevents, but must not add "yes". The "access" tag is a default for all modes not implicitly or explicit handled; there could be, say, osm tags [barrier=stile, access=destination] and this should not imply there is unrestricted foot access. Ticker

3 10

Commit r4482: improve evaluation of barrier=* nodes (barrierAccess.patch by Ticker Berkin)
by svn commit 15 Apr '20

15 Apr '20

Version mkgmap-r4482 was committed by gerd on Wed, 15 Apr 2020 improve evaluation of barrier=* nodes (barrierAccess.patch by Ticker Berkin) Default style "points" has code that, when option --link-pois-to-ways is in effect, sets highway access and speed restrictions that mkgmap then imposes on the highway that the point is on. These rules had various errors: - didn't expand the access mode hierarchy, see https://wiki.openstreetmap.org/wiki/Key:access - tested the wrong tag for mkgmap:bus and mkgmap:delivery - if the "access" tag was set, apply this to all modes before processing allowances and restrictions imposed by the barrier; but these actions would have no effect because the the specified mode tags are now all set - assumed that a gate stops motor_vehicle access - didn't handle other common forms of gate - allowed bicycle through kissing_gate and stile This patch fixes these problems and also adds a speed restriction for all barriers. The general principle is that barrier rules add specific "no" restrictions that the barrier prevents, but must not add "yes". The "access" tag is a default for all modes not implicitly or explicit handled; there could be, say, osm tags [barrier=stile, access=destination] and this should not imply there is unrestricted foot access. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4482

1 0

Commit r4481: Improve documentation of options (Patch by Ticker Berkin)
by svn commit 14 Apr '20

14 Apr '20

Version mkgmap-r4481 was committed by gerd on Tue, 14 Apr 2020 Improve documentation of options (Patch by Ticker Berkin) - layout and spacing - gmapi and family-name - generate-sea options http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4481

1 0

options.txt improvements
by Ticker Berkin 14 Apr '20

14 Apr '20

Hi Gerd Some improvements to options.txt: - layout and spacing - gmapi and family-name - generate-sea options Ticker

1 0

Commit r4480: Ignore tags with empty value when reading OSM files.
by svn commit 13 Apr '20

13 Apr '20

Version mkgmap-r4480 was committed by gerd on Mon, 13 Apr 2020 Ignore tags with empty value when reading OSM files. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4480

1 0

handling of a key without a value
by J J 11 Apr '20

11 Apr '20

https://www.openstreetmap.org/node/7278416985 That node seems to crash my style while trying to execute the following command: ele=* {echo 'ele=${ele}'; set ele_m='${ele|conv:"ft=>m"}'; echo 'ele_m=${ele}'; } The echo command produces "ele=" in the transcript, afterwards "java.lang.StringIndexOutOfBoundsException: String index out of range: -1" etc. The node contains any empty values. "ele" is the only of them my style uses. Observed in: mkgmap-r4478

2 2

splitter and options --description / --geonames-file
by Gerd Petermann 10 Apr '20

10 Apr '20

Hi all, this is a follow up of http://gis.19327.n8.nabble.com/documentation-improvement-tp5962609p5962747.… Since I don't use these options for my maps I am unsure what is best. The --geonames-file option tries to find a city within the calculated tile. If none is found it either writes the value given with --description or just a comment. I think it would be best to always write the nearest city. Gerd

4 9

documentation improvement
by Mike Baggaley 09 Apr '20

09 Apr '20

Hi Gerd, please find attached a small patch that improves the documentation primarily for the following, but with a few other minor tweaks: removal of the statement about putting --description after -c template.args, as this incorrect simplification of the description of --style-file as this was confusing clarification that the number of bytes are the file sizes in the Hill Shading section I note that the '' symbols used to denote arcseconds are being interpreted as italic identifiers <i></i> by whatever process produces the web page. I suggest this process needs to be changed so that this does not happen. I have replaced the first mentions of '' with words. If the process cannot easily be changed, I suggest that the remaining '' symbols are replaced with arc second or arc seconds. I also note that the --dem-dists mentions that values should be a multiple or submultiple of 3314 or 9942 then goes on to suggest values that are multiples of 3312, which I believe is the nearest value to 3314 that is a multiple of 16. I think the explanation needs some improvement by someone who knows exactly how it works. I have been experimenting with various values of --dem-dists - the default value of 9936 works fine for me at higher resolutions in Basecamp, but becomes very blocky at low resolution. I find --dem-dists=9936,9936,9936,9936,9936,9936,39744,317952 gives the best results for my levels of 0:24,1:22,2:21,3:20,4:19,5:18,6:17,7:15. Based on this, I'd be very surprised if the example in the documentation of --dem-dists=3312,13248,26512,53024 for levels 0:24, 1:22, 2:20, 3:18 gives decent results at resolution 18. However, not having any 1 arc second DEM data, I can't try it. Regards, Mike

5 18