[mkgmap-dev] [Patch V1]Re: Still problems with lakes

Thu Oct 18 10:51:54 BST 2012

Hi Steve,

Steve Ratcliffe wrote
> Hello Gerd
> 
>> no, it is not (yet). I plan to add o5m support to mkgmap soon. With my
>> patch you can use splitter
> 
> As an aside, what do you think it is about the o5m format that makes
> it quicker than pbf?

Well, not easy to say. I think it's a combination of many small points:
1) pbf uses (by default) compressied blocks, so you have to unzip a complete
block before you can 
use any information in the block. 
2) pbf read routines create a lot of temporary objects, this seems to stress
GC
3) pbf doesn't allow to skip processing of node tags or way tags, but
splitters' read passes often don't need them. So, with pbf we create lists
of tags and return them to GC, with o5m we can simply skip them.

To be fair, using the --drop-version parm in osmconvert removes a lot of
info which is ignored by splitter and mkgmap. I did never try what effect is
has to use pbf input that was created with this parm.

When writing, o5m is probably only faster because it doesn't zip the data.
As long as mkgmap doesn't understand o5m I see no benefit in using this.

Maybe other computers show different results, esp. if the CPU is much faster
than mine and the Disk access is slower. 
By the way: my patch also speeds up pbf reading a little bit.

Ciao,
Gerd

--
View this message in context: http://gis.19327.n5.nabble.com/Still-problems-with-lakes-tp5725668p5731418.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.