[mkgmap-dev] New splitter version, big memory savings

Thu Sep 3 14:34:49 BST 2009

Hi Steve,

SR> Here are a few ideas based on things that we discovered with earlier
SR> versions of the splitter.

Thanks for this, these points are all new to me.

SR> * Avoid pathalogical behaviour at the poles by limiting latitude to
SR> +- 85.

What should I do with nodes/ways/rels outside this limit? I assume just discard 
them and don't let any tile extend beyond +/-85 (but still include the discarded 
nodes in the overlap)?

SR> * Split tiles that are larger than a given absolute size, as even
SR> an empty file that is big enough will fail.  Not sure what that
SR> size is, but 63240001 is probably over it.

Larger than a specified width or height, or larger than a certain area? What 
exactly do you mean by "will fail" (so I know how to test my changes)?

SR> * There may also be a problem at 180 degrees longitude, caused by the
SR> overlap.  It might work as long as nothing in the chain
SR> normalises, for example, 181 to -179.

Yes I was wondering about this case earlier. Can you explain a bit more what 
you mean by "It might work as long as nothing in the chain normalises" though, 
I'm not sure I follow. Suppose I had a tile that ranges from 170 -> 180. 
If I extend the overlap so that it picks up nodes from say -180 -> -178, 
how does mkgmap deal with that? Or are you suggesting I include those nodes 
but adjust their longitudes to a range of 180 -> 182 instead and mkgmap will 
then do the right thing?

SR> * Trim off areas that are completly empty, this might help with
SR> tiles that are mostly ocean with little bits of land around
SR> the edges.

In the above sentence I take it by "areas" you mean "portions of a single 
tile"? That shouldn't be too hard to do now the density map's in place. By 
the same logic I assume I can throw away completely any tile that contains 
no nodes at all? Is there likely to be any problems as a result of the gaps 
that are introduced between tiles?

Chris