splitter r250 and open questions reg. bounding polygon
Hi all, r250 fixes a performance issue that shows up if you use --keep-complete in combination with a max-areas value which is lower than the actual number of tiles (including the "pseudo-tiles"). Open problems/questions regarding complex bounding polygons: r247 uses such a polygon without problems, but it doesn't try to fit the tiles into the polygon. r248 and above always try to fit the tiles into the polygon and they stop if that is too difficult. I think it would be better to use a compromise: - try to fit into the polygon, if that isn't possible, use it only to "blank out" areas outside of the polygon and allow tiles to (heavily) overlap the polygon. In such a case a warning message should be issued and the resulting shape of the tiles could be output to a file, e.g. areas.poly. (I think that is what Felix suggested?) An alternative would be to use use a new parameter: --fit-into-polygon=true would tell splitter that the user does not want the result if it doesn't fit into the polygon, so it is allowed to stop with an error message if that's not possible. Other ideas? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r250-and-open-questions-reg-bounding... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Am 30.11.2012 10:04, schrieb GerdP:
Hi all,
r250 fixes a performance issue that shows up if you use --keep-complete in combination with a max-areas value which is lower than the actual number of tiles (including the "pseudo-tiles").
Open problems/questions regarding complex bounding polygons: r247 uses such a polygon without problems, but it doesn't try to fit the tiles into the polygon. r248 and above always try to fit the tiles into the polygon and they stop if that is too difficult. I think it would be better to use a compromise: - try to fit into the polygon, if that isn't possible, use it only to "blank out" areas outside of the polygon and allow tiles to (heavily) overlap the polygon. In such a case a warning message should be issued and the resulting shape of the tiles could be output to a file, e.g. areas.poly. (I think that is what Felix suggested?) An alternative would be to use use a new parameter: --fit-into-polygon=true would tell splitter that the user does not want the result if it doesn't fit into the polygon, so it is allowed to stop with an error message if that's not possible.
Other ideas? I would suggest, that the polygon would better, if you create it by yourself. Eg. use --write-kml, open it in josm and create a bounding-polygon (create a way arround the map and then make it smaller with "create area" (x). Then save the created polygon as poly-File. You'll need poly and opendata plugin for josm.
Henning
Henning Scholland wrote
Other ideas? I would suggest, that the polygon would better, if you create it by yourself. Eg. use --write-kml, open it in josm and create a bounding-polygon (create a way arround the map and then make it smaller with "create area" (x). Then save the created polygon as poly-File. You'll need poly and opendata plugin for josm.
Thanks for the hint. I already wondered what I have to do in JOSM to create a nice polygon. Anyway, I think it will help anybody if splitter creates an area.poly that can be used as a starting point. Minko asked via private mail for a splitter that creates tiles which fit exactly into the given polygon if the polygon is rectilinear instead of approximating it with the aligned tiles. I assume this would be good for all? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r250-and-open-questions-reg-bounding... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, First thanks for all the hard work improving the splitter. I'm testing r250 a bit with a small polygon file on the NRW extract. In blue a small polygon file and in red the resulting tiles from the splitter. The borders don't exactly match, the red splitter tiles are outside the polygon rectangular. Is it possible to fit them exactly, because I want to make two maps where the tile borders match exactly at the tile borders (for instance maps of Benelux and Germany). I know I can do this by editting the areas list, but I thought it would be nice if the splitter could handle this for me. BTW I used --keep-complete --overlap=0 --polygon-file=nrw.poly --max-nodes=500000
Why does mkgmap (not mkgmap splitter!) need much more (~20% e.g. on France osm.pbf geofabrik extract) RAM when working with tiles splitted with 250 vs trunk splitter version (using keep-complete and overlap=0)? I didn't try out intermediate versions though. With 8GB Ram on the compiling machine, I needed to back down max-jobs=4 to max-jobs=2 in order to compile France without running out of memory (java xmx 6800M).
Felix Hartmann-2 wrote
Why does mkgmap (not mkgmap splitter!) need much more (~20% e.g. on France osm.pbf geofabrik extract) RAM when working with tiles splitted with 250 vs trunk splitter version (using keep-complete and overlap=0)? I didn't try out intermediate versions though. With 8GB Ram on the compiling machine, I needed to back down max-jobs=4 to max-jobs=2 in order to compile France without running out of memory (java xmx 6800M). _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
Probably because it uses it different algorithm to create the tiles. I assume that you also run into a special case, e.g. with coastlines described here: http://gis.19327.n5.nabble.com/splitter-r246-tp5737445p5737749.html Anyhow, the algorithm in r250 is creating too many tiles, so I am working on a different one. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r250-and-open-questions-reg-bounding... Sent from the Mkgmap Development mailing list archive at Nabble.com.
possible. Please try to make sure to keep the splitter from creating tiles with very few nodes. The current tile algo is less likely to create too large (crashing on compilation) or too small (crashing the gps device). I did notice that it usually created more tiles in comparison with trunk though at same max-nodes setting. On 04.12.2012 16:46, GerdP wrote:
Felix Hartmann-2 wrote
Why does mkgmap (not mkgmap splitter!) need much more (~20% e.g. on France osm.pbf geofabrik extract) RAM when working with tiles splitted with 250 vs trunk splitter version (using keep-complete and overlap=0)? I didn't try out intermediate versions though. With 8GB Ram on the compiling machine, I needed to back down max-jobs=4 to max-jobs=2 in order to compile France without running out of memory (java xmx 6800M). _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Probably because it uses it different algorithm to create the tiles. I assume that you also run into a special case, e.g. with coastlines described here: http://gis.19327.n5.nabble.com/splitter-r246-tp5737445p5737749.html
Anyhow, the algorithm in r250 is creating too many tiles, so I am working on a different one.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r250-and-open-questions-reg-bounding... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Felix Hartmann-2 wrote
possible.
Please try to make sure to keep the splitter from creating tiles with very few nodes. The current tile algo is less likely to create too large (crashing on compilation) or too small (crashing the gps device). I did notice that it usually created more tiles in comparison with trunk though at same max-nodes setting.
sure, that's the main reason for the new algorithm. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r250-and-open-questions-reg-bounding... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (4)
-
Felix Hartmann -
GerdP -
Henning Scholland -
Minko