- mkgmap-dev - The mkgmap lists

patch for "part" filter
by Andrzej Popowski 01 Apr '16

01 Apr '16

Hi, I have tried to use substitution filter "part" and have found, that it worked differently, than I expected. Some operation results in adding trailing separator while others don't. Some filters return null, others return "", which breaks evaluating formulas with "|". I have attached a patch, that should change behavior of following filters: "A1;A2;A3" "part:;<3" -> old "A3;", patched "A3" "A1;A2" "part:;<3" -> old null, patched "A1;A2" "A1" "part:;>-2" -> old null, patched "A1" "A1;A2;A3" "part:;>3" -> old "", patched null "A1;A2" "part:;<-2" -> old "", patched null I have attached example data and style for testing the filter. I'm not sure, what would be preferred result for following filters: "A1" "part:;<3" -> result null or "A1"? "A1" "part:;>-3" -> result null or "A1"? Both, current version and patched, return null. I think result "A1" could be useful. -- Best regards, Andrzej

2 2

Commit r3675: dest_hint_v1.patch : change --process-destination option
by svn commit 01 Apr '16

01 Apr '16

Version mkgmap-r3675 was committed by gerd on Fri, 01 Apr 2016 dest_hint_v1.patch : change --process-destination option The process_destination option was a bit problematic because it could have added the tag destination=* to an existing OSM element. The attached patch changes the method like this: 1) the tag destination is not changed by mkgmap 2) Instead the special tag mkgmap:dest_hint is now set to the destination string that was found in one of the tags listed in this code snippet: tags.add("destination"); tags.add("destination:lanes"); tags.add("destination:lanes:forward"); tags.add("destination:lanes:backward"); tags.add("destination:forward"); tags.add("destination:backward"); tags.add("destination:street"); (BTW: This is also the order of evaluation in mkgmap searches since r3673, of cause forward/backward are checked depending on the direction of the way) For style authors this means that they have to 1) change all rules with mkgmap:dest_hint=true to mkgmap:dest_hint=* 2) change the rule that produces the hint to something like this: mkgmap:dest_hint=* { set dest_hint = '${destination:ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' | '${ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' | '${mkgmap:dest_hint|subst:;=> |subst:/=> }'; } Basically all places where "destination" was used were changed to mkgmap:dest_hint. This could cause trouble, so I've added a check that complains when the style contains an expression mkgmap:dest_hint=true. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3675

2 1

[Patch v1] change process-destination option
by Gerd Petermann 30 Mar '16

30 Mar '16

Hi all, please read carefully: Up to now the process_destination option is a bit problematic because it may add the tag destination=* to an existing OSM element, and I think this is not good, all tags added by mkgmap should have the mkgmap: prefix. As Greg pointed out this causes problems for style authors who want to create special hints depending on tags like destination:street . The attached patch changes the method like this: 1) the tag destination is not changed by mkgmap 2) Instead the special tag mkgmap:dest_hint is now set to the destination string that was found in one of the tags listed in this code snippet: tags.add("destination"); tags.add("destination:lanes"); tags.add("destination:lanes:forward"); tags.add("destination:lanes:backward"); tags.add("destination:forward"); tags.add("destination:backward"); tags.add("destination:street"); (BTW: This is also the order of evaluation in mkgmap searches since r3673, of cause forward/backward are checked depending on the direction of the way) For style authors this means that they have to 1) change all rules with mkgmap:dest_hint=true to mkgmap:dest_hint=* 2) change the rule that produces the hint to something like this: mkgmap:dest_hint=* { set dest_hint = '${destination:ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' | '${ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' | '${mkgmap:dest_hint|subst:;=> |subst:/=> }'; } Basically all places where "destination" was used were changed to mkgmap:dest_hint. I am aware that this could cause trouble, so I've added a check that complains when the style contains an expression mkgmap:dest_hint=true . A binary can be found here: http://files.mkgmap.org.uk/download/295/mkgmap.jar With the default style this produces the same img file as r3673. Please let me know if you see problems with your style. Gerd

3 9

style parsing problem since r3671
by Lutz Mändle 30 Mar '16

30 Mar '16

Hi, since mkgmap r3671 the following statement in my lines-file is marked as error: railway=* & (gauge ~ '\d*;1435' | gauge ~ '1435;\d*') & building!=* & area!=yes & tunnel=yes [0x11e11 resolution 19] The error message is: Error in style: Error: (lines:196): Invalid rule expression: ((($gauge~'\d*;1435')|($gauge~'1435;\d*'))&(($building!=*&($area!=yes&($tunnel='yes')))&$railway=*)) Could not open style maendle Number of ExitExceptions: 1 Omitting the term "& tunnel=yes" makes the parser happy, but that's not what I want. Rearranging the statement to this form railway=* & building!=* & area!=yes & tunnel=yes & (gauge ~ '\d*;1435' | gauge ~ '1435;\d*') [0x11e11 resolution 19] solves the problem. I discovered this problem in r3672 and guess r3671 introduced it, until r3669 it was fine, in the actual r3674 the problem persists. -- Lutz Mändle Internet: lmaendle(a)gmx.net Berlin/Germany

1 0

overview map creation
by Gerd Petermann 30 Mar '16

30 Mar '16

Hi all, while writing this answer http://gis.19327.n5.nabble.com/img-limit-tt5870924.html#a5870939 I wondered in what cases mkgmap calculates the overview map. I am not sure why, but it seems that it does that whenever it is told to process any input file (OSM or polish format). As I wrote in my answer you can use --no-tdbfile to switch off this, but that also prohibits the creation of the work files named ovm_*.img. I see one case where this can cause problems even with a "normal" style: If you want to calculate all tiles for the whole planet first and combine them later into individual maps you probably will run into the size limit when mkgmap finally calculates an overview map for planet. Sure, one can ignore this error as all other img files should be okay, but I think it would be better to create the overview map only when it is really needed, means, when --nsis or --tdbfile is given. Did I get this right? What is your opinion? Gerd

1 0

img limit
by Steve Sgalowski 30 Mar '16

30 Mar '16

what is the max limit on the gmapsupp .img file size? is there a reason why it wont go past 3 gb , even with keep going switch applied Stephen

4 3

Problem with splitter: Failed to find a correct split
by KeenOnKites 26 Mar '16

26 Mar '16

Hello together, I'm running into a problem with the splitter (r435 aswell as r427) when splitting the US_ALASKA file downloadable from Geofabrik. The exception is: Warning: No solution found for partition (49.7900390625,-179.9560546875) to (73.828125,180.0) with 6'702'717 nodes uk.me.parabola.splitter.SplitFailedException: Failed to find a correct split at uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:152) at uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:196) at uk.me.parabola.splitter.Main.calculateAreas(Main.java:645) at uk.me.parabola.splitter.Main.split(Main.java:258) at uk.me.parabola.splitter.Main.start(Main.java:187) at uk.me.parabola.splitter.Main.main(Main.java:157) The complete command line with the splitter call is: java -Xmx1536M -jar D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar --max-threads=2 --geonames-file=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/c ities15000.zip --no-trim --precomp-sea=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea --keep-complete=true --mapid=98200001 --max-nodes=800000 --output=xml --output-dir=D:/fzk/develop/fzk -mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf The pbf source file comes from: http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf The osmconvert statistics about that file is: PS Freizeitkarte-Entwicklung> .\tools\osmconvert\windows\osmconvert.exe .\work\Freizeitkarte_US_ALASKA\Freizeitkarte_US_ALASKA.osm.pbf --out-statistics timestamp min: 2007-06-05T03:23:59Z timestamp max: 2016-03-23T05:41:43Z lon min: -180.0000000 lon max: -122.5122525 lat min: 48.6234931 lat max: 71.6061501 nodes: 4360214 ways: 185550 relations: 2245 node id min: 27207079 node id max: 4072166815 way id min: 4708608 way id max: 404980503 relation id min: 13971 relation id max: 6033189 keyval pairs max: 310 keyval pairs max object: relation 60189 noderefs max: 2000 noderefs max object: way 42394334 relrefs max: 681 relrefs max object: relation 3337277 PS Freizeitkarte-Entwicklung> Interesting to mention: - splitter exception mentiones a complete different coverage area than osmconvert statistics. - the area is near -180 / +180... always complicated. Do I miss something ? All other pbf's I've tried are splitting properly without any problems. Do I need to change something in the arguments ? Or is it a simple problem of the actual pbf file ? Any ideas are very welcome.... Cheers Patrik

5 27

Commit r3674: The mdr1 index must be sorted in map order.
by svn commit 25 Mar '16

25 Mar '16

Version mkgmap-r3674 was committed by steve on Fri, 25 Mar 2016 The mdr1 index must be sorted in map order. Normally files are in the correct order to start with. However if they do need to be reordered, then the existing code does not work correctly. Remove the existing complex code and now just sort the map command line arguments after they maps are compiled and before the index generation is started. This also means that files other than .img files are also re-ordered, so there may be side effects. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3674

1 0

osm combiner error
by Minko 25 Mar '16

25 Mar '16

Hi, On the osm forum someone reported this error with OSM combiner (http://www.openfietsmap.nl/news/osmcombiner) (mkgmap r.3654) http://forum.openstreetmap.org/viewtopic.php?id=30632 What does Unsupported major.minor version 51.0 mean? ------------------ Unfortunately the new OSM Combiner 1.8 did not solve the problem for me. I dowloaded a fresh set of osm_generic_tiles.zip files for the Netherlands, Belgium and France and tried to combine them with OSM combiner 1.8 but consistently get an error message (see below). All steps up to "Start" work, the final step fails and gives the error message. I use MacOS 10.11.3 with the latest Java installed and allocated 5gb of memory to Java, disk space is plenty. What am I doing wrong? Thank you! --- Error message: Exception in thread "main" java.lang.UnsupportedClassVersionError: uk/me/parabola/mkgmap/main/Main : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

5 7

last release
by Steve Sgalowski 25 Mar '16

25 Mar '16

the last release is not yet uploaded on the site 3673 dated 23 march Stephen This email has been sent from a virus-free computer protected by Avast. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 2