- mkgmap-dev - The mkgmap lists

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

New style branch
by Steve Ratcliffe 11 Aug '17

11 Aug '17

Hi Every now and again, there is a bug report on a style rule that gives an error when it shouldn't. The most recent from Mike Baggaley, included a case where the rule was accepted but the result was incorrect. I wrote a little program to generate random rules and test them using the style tester. This showed that there were many rules that should be accepted that are not and worse there are cases where the wrong result is given. Worst of all this simple rule: a>=1 & (a=1 | b~2) [0x2] (and many others) crash mkgmap with a StackOverflowError. I'm surprised that no-one has found that. Perhaps they have and it just hasn't been reported. An example of a rule that is accepted but doesn't work is: (a!=1 | b~2) & a<2 & a>=2 [0x2] This matches (with trunk) with a way with tags a=2 and b=2 but it should not. So not very complex rules fail. There are also vast number of rules that involve using not (!) such as !(highway=service & ...) that are not accepted or do not work. Probably not many styles have many such rules though. So I re-wrote and simplified the code and the result is on the expr branch. There is also a new feature that was needed to help make it work. There is now a not regex match operator !~. It is probably not all that useful but it is now availabl. name !~ 'Main.*' is exactly the same as !(name ~ 'Main.*') The latest branch build can be downloaded from: http://www.mkgmap.org.uk/download/mkgmap-expr-latest.zip It is important to test it, as although I believe that the branch is now correct, some styles may have been relying on previous bugs. ..Steve

3 4

Basecamp crashes with my map
by thesurveyor＠wolke7.net 10 Aug '17

10 Aug '17

3 10

Commit r3980: improve logging for StyledConverter.roads : Report also road class and speed
by svn commit 05 Aug '17

05 Aug '17

Version mkgmap-r3980 was committed by gerd on Sat, 05 Aug 2017 improve logging for StyledConverter.roads : Report also road class and speed I uised this to check the effect of routing.patch (r3979). http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3980

1 0

Commit r3979: routing.patch by Andrzej Popowski (slightly modified)
by svn commit 05 Aug '17

05 Aug '17

Version mkgmap-r3979 was committed by gerd on Sat, 05 Aug 2017 routing.patch by Andrzej Popowski (slightly modified) Comment from Andrzej: The patch address 2 problems in default style. First are links and roundabouts, which often get lower road class than connected roads. This breaks continuity of high class network and breaks routing. My patch simply increases road class for many links and roundabout types. Second problem is low density of good highways in some regions. To make it better, my patch increases road class for international roads. These roads are detected by "ref" and "int_ref" tags, both in objects and relations. I have added some small general corrections for "highway=mini_roundabout", "access=hov" and "oneway=reversible". http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3979

1 0

Find Address - No cities
by Ticker Berkin 04 Aug '17

04 Aug '17

I have a strange problem. With a particular split of 'british-isles', one map from the split causes the list of cities in the Find>Address function to be empty. Find>Address does still find streets, but not this is not very useful when cannot limit by City first. Excluding this particular map but leaving everything else unchanged, the city list is there and works as expected. The list of cities in Find>City is correct. The same problem occurs on an old build of mkgmap (r3694). Splitting with a reduced --max_nodes, the problem goes away. Also I think some minor changes to my style has caused the problem to come and go. I', using Etrex Legend, --gmapsupp --index --route and various other options. Any ideas about how to debug this? Thanks Ticker

4 17