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.h... Sent from the Mkgmap Development mailing list archive at Nabble.com.