August 2017 - mkgmap-dev - The mkgmap lists

Colouring of island not correct
by Christoph Karl 20 Aug '17

20 Aug '17

Hi! I tried to generate a gmapsupp.img with mkgmap. I have done this with: /usr/java/jdk1.8.0_144/bin/java -Xmx8G -jar ./mkgmap-r3993/mkgmap.jar -- gmapsupp karten/corse-latest.osm.pbf But the colouring of the landscape is not correct. See "corse_wrong_colour.png" Compared to "bremen_correct.png" Screenshots are made from qlandkartegt Version 1.8.1. I also tried to use "--precomp-sea=./karten/sea.zip", but this just colours the surrounding sea. Do you have any ideas? Thank you Best Regards Christoph

2 3

"shop=no"
by Bernhard Hiller 20 Aug '17

20 Aug '17

In the forum, there is a discussion on the enormous variety of values for some tags, see https://forum.openstreetmap.org/viewtopic.php?id=55541 (in Dutch). There is also a link to a list showing the different values for the "shop" tag: http://mijndev.openstreetmap.nl/~marczoutendijk/taginfo-shop.html You can see there that the combination "shop=no" exists 2372 times, "shop=none" 4 times. With our current default style, they'd be summed up by the line shop=* [0x2e0c resolution 24] which just would make them into a shop. I guess we should better ignore the shop=no/none combination (note: a value containing "no" may still be correct), and provide a PoI based on the other tags for that node. What do you think? Regards, Bernhard

3 4

Commit r3994: default style: change handling of place=island and place=islet in polygons
by svn commit 20 Aug '17

20 Aug '17

Version mkgmap-r3994 was committed by gerd on Sun, 20 Aug 2017 default style: change handling of place=island and place=islet in polygons 1) Move the rules below the evaluation of landuse and natural tags so that those tags are preferred 2) Ignore huge place=islands as type 0x53 is not suitable for them http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3994

1 0

How to identify beginning and end of a route?
by nwillink 18 Aug '17

18 Aug '17

Hi I read the following: Matching member roles by regular expression Currently, apply role=value is for fixed strings. I'm not quite sure what 'fixed strings ' means but perhaps it means that the unique properties of individual members of a relation cannot be parsed. This is a shame as it would be great to mark the start and end of cycling / hiking routes. In osm we can mark the start of a route using role="start" ,ie <member type="node" ref="454189725" role="start"/> <tag k="name" v="Otter Valley Walk"/> <tag k="network" v="rwn"/> <tag k="osmc:symbol" v="blue:green:yellow_pointer"/> <tag k="ref" v="OVW"/> <tag k="roundtrip" v="no"/> <tag k="route" v="foot"/> <tag k="type" v="route"/> </relation> However, I've not been able to capture this node. I wonder if anyone has an answer? r Nick -- View this message in context: http://gis.19327.n8.nabble.com/How-to-identify-beginning-and-end-of-a-route… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 3

mkgmap:fast_road
by Alexandre Loss 18 Aug '17

18 Aug '17

Hi Gerd, Sorry If I missed the discussion about the tag "mkgmap: fast_road", but I did not see anything about this in the manual and neither searching the net. I became aware of this tag by downloading the mkgmap 3993 and analyzing the changes in the standard "line" and "relation" files. What is the pratical result/behavior of this tag in the routing? Thanks. Alexandre Loss

3 7

MapFailedException when generating map for Italy
by Walter Schlögl 17 Aug '17

17 Aug '17

I am generating many maps without any error, only the area of Italy is throwing an error which I cannot solve. I hope, anybody is having an idea, what could be the solution. The coordinates are: 4.4°O – 21.1°O and 35°N - 45°N The error message: SCHWERWIEGEND (MapFailedException): 50100004.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SCHWERWIEGEND (MapFailedException): 50100009.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SCHWERWIEGEND (MapFailedException): 50100017.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SCHWERWIEGEND (MapFailedException): 50100018.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SCHWERWIEGEND (MapFailedException): 50100021.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SCHWERWIEGEND (MapFailedException): 50100023.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SCHWERWIEGEND (StyledConverter): 50100025.o5m: Attention: Tile contains both drive-on-left (16159) and drive-on-right roads (21405) SCHWERWIEGEND (MapFailedException): 50100025.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SCHWERWIEGEND (MapFailedException): 50100028.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. SCHWERWIEGEND (RouteArc): 50100031.o5m: Way SS116 Strada Statale 116 Randazzo - Capo d'Orlando (id 195550142) contains an arc whose length (5717225 units) is too big to be encoded, using length 4194303 SCHWERWIEGEND (RouteArc): 50100031.o5m: Way SS116 Strada Statale 116 Randazzo - Capo d'Orlando (id 195550142) contains an arc whose length (5717225 units) is too big to be encoded, using length 4194303 SCHWERWIEGEND (RouteArc): 50100031.o5m: Way SS116 Strada Statale 116 Randazzo - Capo d'Orlando (id 195550142) contains an arc whose length (5717225 units) is too big to be encoded, using length 4194303 SCHWERWIEGEND (RouteArc): 50100031.o5m: Way SS116 Strada Statale 116 Randazzo - Capo d'Orlando (id 195550142) contains an arc whose length (5717225 units) is too big to be encoded, using length 4194303 SCHWERWIEGEND (RouteArc): 50100031.o5m: Way SS116 Strada Statale 116 Randazzo - Capo d'Orlando (id 195550142) contains an arc whose length (5327027 units) is too big to be encoded, using length 4194303 SCHWERWIEGEND (RouteArc): 50100031.o5m: Way SS116 Strada Statale 116 Randazzo - Capo d'Orlando (id 195550142) contains an arc whose length (5327027 units) is too big to be encoded, using length 4194303 SCHWERWIEGEND (RouteArc): 50100031.o5m: Way SS116 Strada Statale 116 Randazzo - Capo d'Orlando (id 195550142) contains an arc whose length (5327027 units) is too big to be encoded, using length 4194303 SCHWERWIEGEND (RouteArc): 50100031.o5m: Way SS116 Strada Statale 116 Randazzo - Capo d'Orlando (id 195550142) contains an arc whose length (5327027 units) is too big to be encoded, using length 4194303 SCHWERWIEGEND (MapFailedException): 50100034.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. java.lang.NullPointerException at uk.me.parabola.imgfmt.app.Coord.distanceInDegreesSquared(Coord.java:425) at uk.me.parabola.imgfmt.app.Coord.distance(Coord.java:409) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGroup.findSegment(HousenumberGroup.java:151) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberRoad.detectGroups(HousenumberRoad.java:205) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberRoad.buildIntervals(HousenumberRoad.java:104) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.generate(HousenumberGenerator.java:706) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:624) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:246) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:138) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:265) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:261) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option Walter Schlögl

2 12

[Patch v1] Simple data integrety check for mkgmap
by Gerd Petermann 17 Aug '17

17 Aug '17

Hi all, not sure if this is usefull: It happened a few times in the past that either I/O errors or badly merged data caused invalid coordinates. As a result, mkgmap shows rather misleading error messages as reported by Walter: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q3/026994.html The attached patch implements a simple check: Calculate the bounding box for each way with the tag building=yes and print an error message when the bbox is > 1000 garmin units in width or height. If more than 10 such objects were found the tile is not processed. The calculation is done before style processing and it is simple, so performance is no issue. I've checked also some good files to make sure that it doesn't produce (too many) false positives. One small problem: If the style files for ways don't check the building tag at all the tag is removed and therefore the test might not work. I can change that but I think most styles evaluate the tag. What do you think? Do we need paramters to control this ? Gerd P.S. A sample output for the corrupted tile from Walter looks like this, please suggest better messages if you don't like them: Time started: Thu Aug 17 11:34:23 CEST 2017 SCHWERWIEGEND (StyledConverter): e:\walter\50100031.o5m: Data integrety check failed: Building polygon has huge bbox http://www.openstreetmap.org/way/186387851 SCHWERWIEGEND (StyledConverter): e:\walter\50100031.o5m: Data integrety check failed: Building polygon has huge bbox http://www.openstreetmap.org/way/186387875 ... SCHWERWIEGEND (StyledConverter): e:\walter\50100031.o5m: Data integrety check failed: Building polygon has huge bbox http://www.openstreetmap.org/way/219675499 SCHWERWIEGEND (StyledConverter): e:\walter\50100031.o5m: Data integrety check failed: Building polygon has huge bbox http://www.openstreetmap.org/way/219675542 SCHWERWIEGEND (StyledConverter): e:\walter\50100031.o5m: Data integrety check failed: Building polygon has huge bbox http://www.openstreetmap.org/way/219675525 SCHWERWIEGEND (MapFailedException): e:\walter\50100031.o5m: (thrown in StyledConverter.end()) Input file seems to be corrupted, counted 826 unplausable objects Number of MapFailedExceptions: 1 Number of ExitExceptions: 0 Time finished: Thu Aug 17 11:34:33 CEST 2017 Total time taken: 9888ms

1 0

Commit r3993: don't create shop POI for shop=no or shop=none
by svn commit 16 Aug '17

16 Aug '17

Version mkgmap-r3993 was committed by gerd on Wed, 16 Aug 2017 don't create shop POI for shop=no or shop=none http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3993

1 0

Empty name
by Pedro Torres 15 Aug '17

15 Aug '17

Hello, I am using mkgmap-r3980 and I having the same problem reported a long time ago here but with no clear solution. The problem is the map name in Basecamp or MapManager (OSX, all softwares up to date). The name is always empty. Here is the line I am using to build my map: java -Xmx2000m -jar ../mkgmap.jar --max-jobs=2 --keep-going --gmapi --gmapsupp --mapname=20170814 --description="My Desc" --index --product-version=101 --overview-mapname="Overview Name" --series-name="Series Name" --family-name="Family Name" --route --area-name="Area" --precomp-sea=../data/sea.zip path/to/*.pbf I appreciate any help, Pedro

3 3

Commit r3992: add check to avoid NPE
by svn commit 15 Aug '17

15 Aug '17

Version mkgmap-r3992 was committed by gerd on Tue, 15 Aug 2017 add check to avoid NPE The problem seems only to occur with corrupted OSM data, but mkgmap should not simply crash. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3992

1 0