September 2020 - mkgmap-dev - The mkgmap lists

Error in Africa?
by valentin3151＠gmail.com 14 Sep '20

14 Sep '20

Hi all, My daily compilation of Africa was stopped because error is appear: SEVERE (MapSplitter): 63240201.osm.pbf: Single item predicted to exceed subdivision http://www.openstreetmap.org/?mlat=10.412207&mlon=-13.010709&zoom=17 Number of MapFailedExceptions: 0 Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 113, Size: 3 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.imgfmt.app.net.NETFileReader.getRoads(NETFileReader.java:116) at uk.me.parabola.imgfmt.app.map.MapReader.getRoads(MapReader.java:205) at uk.me.parabola.mkgmap.combiners.MdrBuilder.addStreets(MdrBuilder.java:298) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:171) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onMapEnd(GmapsuppBuilder.java:164) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:665) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:125) at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:144) at uk.me.parabola.mkgmap.main.Main.main(Main.java:115) Link to my tile where the error is: https://maptourist.org/tmp/63240201.osm.pbf I tried to find the cause of this error in OSM but could not. The link from above error log points to the location with completely no data somewhere in the middle of Guinea. As an experiment, I loaded the problem tile into JOSM and fixed all automatically found errors. Then I tried to compile the corrected file. No positive effect. The error is still there. I use mkgmap-r4564, but I found there is no dependency with other versions. How do I find what exactly is causing this error in the OSM data? Previously, this map was compiled many times over a long time without such problem. -- Best regards, Valentin mailto:valentin3151@gmail.com

4 17

highway=unclassified & area=yes
by Ticker Berkin 14 Sep '20

14 Sep '20

Hi all Diagnosing what seemed like superfluous navigation pop-up, eg "Turn left on A1", while driving on the A1, I discover quite a few junctions are surrounded by a closed way with tags [highway=unclassified, area=yes] https://www.openstreetmap.org/way/239371846 https://www.openstreetmap.org/way/239371836 https://www.openstreetmap.org/way/239754207 and these "way"s, with the default style (and all other styles I've ever looked at) will generated a road that probably shares many routing points with the real roads in the junction. These seem to be used for documentation of changes and are possibly being create automatically by some OSM editing tool. I haven't found any references to this being something that is acceptable or is wrong, so I don't know if these should be deleted from OSM and/or ignored by the mkgmap style. Thoughts anyone - Ticker

8 12

DEM display level.
by Joao Almeida 14 Sep '20

14 Sep '20

Hi, I have a question about the behavior of mkgmap. If I build 2 different maps using the same exact settings I get 2 different outputs for DEM display. Let me try to explain. my settings for DEM : --overview-dem-dist=88888 --dem-dists=9942 If I build a map, let's say Mongolia, I have DEM rendering from zoom level 3000km in basecamp... obviously not very useful but it is there. If I build another map, let's say of europe, the DEM rendering only occurs at zoomlevel 30km and below to 20m. Does anyone know why? Thank you Joao

2 3

precomp sea test environment
by Gerd Petermann 14 Sep '20

14 Sep '20

Hi all, today I stumbled over a bad sea.zip file that was created in 2019-11-08. Most of the two Americas was flooded. I wondered if I should add some code to mkgmap to detect this case? Eg. mkgmap could check some points which are clearly inside continents. Besides that it is rather simple to produce a test style for the sea which just creates an overview map. I've created some empty tiles which cover full planet and used them to create an overview map containing only sea polygons. This compilation takes ~1 minute. A quick glance at osmmap.img should show the familiar shapes of the continents, if not something is wrong and that probably means that the precomp-sea data is bad. I've attached this, maybe it is of some help. Gerd

4 6

Re: [mkgmap-dev] highway=unclassified & area=yes
by dd8kq 13 Sep '20

13 Sep '20

ThanksMit freundlichem Gruß Manfred Haiduk -------- Ursprüngliche Nachricht -------- Von: Ticker Berkin <rwb-mkgmap(a)jagit.co.uk> Datum: 13.09.2020 11:48 (GMT+01:00) An: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] highway=unclassified & area=yes HiIn styles / default / lines, around line 181, the change would be:highway=unclassified [0x06 road_class=0 road_speed=3 resolution 21]to:highway=unclassified & area!=yes [0x06 road_class=0 road_speed=3resolution 21]If you style has a mop-up for unhandled highways, make sure that thisisn't triggeredTickerOn Sun, 2020-09-13 at 11:09 +0200, DD8KQ wrote:> Hi Ticker> > just for me a hint, how can i ignore this in a style ?> _______________________________________________mkgmap-dev mailing listmkgmap-dev@lists.mkgmap.org.ukhttp://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1 0

mkgmap skips multipolygon with no nodes in map area
by Ranko Jaksic 12 Sep '20

12 Sep '20

Hi Gerd, Recently I discovered a missing forest "triangle" on my map (see attached screenshots). I am using the same mkgmap/splitter (4551/597) versions as before, but obviously OSM data changed so splitter generated a slightly different areas.list The forest in question consists of two very large multipolygons: https://www.openstreetmap.org/relation/1431438 https://www.openstreetmap.org/relation/4433469 Both relations cover the map-tile area, but mkgmap creates no polygon for the second one. It supose it doesn't get detected in mkgmap because it has no nodes in the area (splitter has no such problem: it detects the multipolygon and includes it in the output file). I am including my test data: - forest.osm.pbf - contains only these two relations (or use croatia-latest.osm.pbf extract from Geofabrik :) - areas-test.list - area in question - forest-typ.txt - simple typ file to display forest (not really needed) test code: java -jar splitter.jar --split-file=areas-test.list forest.osm.pbf java -jar mkgmap.jar -c template.args forest-typ.txt --gmapi --remove-ovm-work-files Splitter includes both relations in the 88010024.osm.pbf, but mkgmap includes only the first one in the generated 88010024.img file. regards, Ranko

2 2

Commit r4574: correction: In rare cases a multipolygon was ignored.
by svn commit 12 Sep '20

12 Sep '20

Version mkgmap-r4574 was committed by gerd on Sat, 12 Sep 2020 correction: In rare cases a multipolygon was ignored. This happened when none of the polygon points was inside the tile and an edge of the MP crossed the tile bounds. Thanks to Ranko Jaksic for reporting this very old bug. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4574

1 0

Commit r4573: merge the map-split branch
by svn commit 11 Sep '20

11 Sep '20

Version mkgmap-r4573 was committed by gerd on Fri, 11 Sep 2020 merge the map-split branch http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4573

1 0

Commit r4568: - split road in StyledConverter if it has too many points. A road can refer to max 127 Polylines (each with < 255) points
by svn commit 08 Sep '20

08 Sep '20

Version mkgmap-r4568 was committed by gerd on Tue, 08 Sep 2020 - split road in StyledConverter if it has too many points. A road can refer to max 127 Polylines (each with < 255) points - reduce severity for size check as there is no problem with a single object that requires more than MAX_RGN_SIZE bytes - change assert to throw MapFailedException when road has more than 127 Polylines (should never happen) The code in MapSplitter might need more changes. It checks for limits which don't exist in the IMG format. As long as WANTED_MAX_AREA_SIZE is smaller than MAX_RGN_SIZE this doesn't seem to produce problems. I think a size problem only occurs when a MapArea contains different kinds of objects, e.g. lines and polygons. A 16 bit offset is written to indicate the position of the first object of each further kind. This offset must not be too large and thus the preceding data must fit into an area less than ~0xfff8. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4568

1 0

Commit r4567: detect and report invalid lon/lat values in *.poly files
by svn commit 06 Sep '20

06 Sep '20

Version mkgmap-r4567 was committed by gerd on Sun, 06 Sep 2020 detect and report invalid lon/lat values in *.poly files http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4567

1 0