
On 19.12.2012 17:15, GerdP wrote:
Hi all,
some time ago we discussed whether splitter could somehow exchange information with mkgmap. I think the idea was that mkgmap (or the style system) can remove many or all nodes from a tile which leads to problems. I assume this problem is solved with the new split algorithm? If not: Splitter writes the file densities-out.txt, which contains the node counters. It can also read that file, and it would not be very difficult to manipulate the counters somehow. yes, I didn't actually check it on the device, but the tiles in France are now never empty, so I think it's highly unlikely to run into the bug again (only if people added loads of open sea map data).
I stll see one option to improve splitter throughput: Before reading any osm file, mkgmap creates a list of all tag keys which are needed (hard coded keys and those from the style files). All other tags are simply ignored when reading OSM data to save memory. If we would give this list to splitter we could probably save a lot of processing time when splitter ignores these tags as well. On the other hand, you have to execute splitter again if you change a style.
What do you think?
Gerd I think that sounds very cool as an option. It could be switched off if you play a lot - but then in generall, splitter is much faster than mkgmap anyhow, so it's rather seldom that it would matter to me...
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-fine-tuning-tp5741064.html 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