[mkgmap-dev] Binary format update

Thu Sep 16 19:55:55 BST 2010

> On Thu, Sep 16, 2010 at 12:33 PM, WanMil<wmgcnfg at 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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>