On Thu, Sep 16, 2010 at 12:33 PM, WanMil<wmgcnfg@web.de> wrote:
Hi Steve,
that was a quick implementation!
I haven't tried so far the new binary format. I haven't found a download for the osmprotobuf.jar. Is there any? Download links should be added to the documentation and the website if the changes are merged back.
I am still in release candidate status as far as jar is concerned. At present, I haven't set up hosting for it anyplace. The best place to get it right now is from osmosis trunk ('osmbin.jar'), or build it from my git repository on github.
Thanks for the hint!
I had some thoughts if the splitter is still needed with this new format. The website of the new protocol tells me that the operation getNodesbyBoundingBox(north,south,east,west) is supported. So it should be possible to start mkgmap with the bbox definition of all tiles (like the areas.list file of the tile splitter) and a planet dump file? The splitter work could be reduced to generate a reasonable areas.list file. Are there any objections on this?
This could be done, but the data has to be geographically sorted. I've described how to do that, but the code implementing it hasn't been written.
Ok, that means we cannot use the common planet dumps for this and a separate step (geographical sorting) is needed which maybe eats up the advantage to skip the tile splitter step. Just keep the idea in mind and give it a try when the geographical sorting is available.
I've got a question though, why can't mkgmap generate different areas in parallel? It seems like it should be possible and it would make it a lot faster to render maps.
mkgmap already works in parallel if you specifiy multiple osm files which are usually generated by the tile splitter (see parameter --max-jobs). The advantage of my idea would be to skip the tile splitter step. WanMil
Scott _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev