[mkgmap-dev] splitter: option for maximum tile area?From Bernhard Hiller bhil at gmx.de on Tue Nov 6 13:54:00 GMT 2018
Thanks all, meanwhile I could generate a map which looks fine in QLandkarte and on my Oregon. I'd like to summarize the findings for those who try to create contour lines with srtm2osm and feed them into a Garmin map. I updated the wiki page https://wiki.openstreetmap.org/wiki/Srtm2Osm First of all, it is possible to use srtm2osm with elevation data downloaded from Viewfinderpanoramas and unzipped into its cache folder. In contrast to what one might expect, the folder where the *.hgt files must be placed is not the folder indicated with the -d option, but a folder "SrtmCache" below it (that's hard coded in the source code of srtm2osm). Next, the default start ids for nodes and ways generated by the program is long.MaxValue, which is a reserved value in splitter, thus causing an exception (see a previous thread: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q4/029073.html ). The options -firstnodeid 9023372036854775807 -firstwayid 9023372036854775807 (or other high values less than long.MaxValue) remove this issue. It is important to note that a misspelled option will not cause an error message by srtm2osm - that option is merely ignored. So do not feel surprised when a problem later on a step later on just happened again, though you thought that you changed something before... Another issue is the unlimited size of ways. In OSM data, ways longer than 2000 nodes do likely not exist because the API prevents the upload of such long ways. But srtm2osm produced ways with more than a hundred thousand nodes. splitter tries to keep ways complete. The long ways lead to a slow processing by splitter, and to an extremely inflated size of the tiles created by splitter (if the original file and the tiles have the same format, the sum of file sizes of the tiles should not be much more than the file size of the original file): upto 9 times the original size. There after, mkgmap crashes with an OutOfMemory error. The solution is to limit the file size with option -maxwaynodes 5000 (or an even lower value: the files were still inflated by about a half). Adding the option --precomp-sea to the splitter options is irrelevant for the OutOfMemory exception in mkgmap. Also, the value of the --max-nodes splitter option proofed irrelevant for the exception. Running mkgmap with --max-jobs=3 instead of 4 was also irrelevant. But running splitter with a high value of --max-nodes in combination with --precomp-sea lead to a different exception in mkgmap: (MapFailedException): 47120100.osm.pbf: (thrown in RoadDef.writeRgnOffsets()) Overflow of the NET1. The tile (47120100.osm.pbf) must be split so that there are fewer roads in it Then, that tile was left empty. I could see this issue with big cities (Bangkok, Kuala Lumpur) now, but never experienced it before (I created a map of Central Europe with a value of 3 million without precomp-sea - absolutely no problem). I hope this information won't be outdated when some else tries to follow these steps. Kind regards, Bernhard Am 31.10.2018 um 22:03 schrieb Bernhard Hiller: > Hi all, > currently a Java OutOfMemory exception prevents me from creating a > map. I already use option --max-jobs=3 (the machine has 4 physical > cores) and -Xmx5G (of 8 GB installed). Beyond OSM data, the map > contains DEM and elevation contour lines. > From the tiles finished and those with a new timestamp but about 0 > bytes length, I can see that mkgmap was rendering tiles 47120005, > 47120006, 47120007 at the time of crash. > Tile 47120005 is extremely large by physical area - some 6° x 5.5° > (see attached file), covering a lot of the south chinese sea, i.e. > there are not many actual data in that area. > I guess that the problem arises with that tile. I remember some case > in the past where a single tile covering such a large area of mainly > sea caused mkgmap to take an enormous amount of time for rendering - > also here, mkgmap already spent about 1 hour before crashing. > So I'd like to ask: is there some possibility for limiting the area of > a tile among the splitter options? > Kind regards, > Bernhard
- Previous message: [mkgmap-dev] splitter: option for maximum tile area?
- Next message: [mkgmap-dev] splitter: option for maximum tile area?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list