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

Thu Sep 3 16:17:14 BST 2009

Hi Chris

> 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)?

I wasn't thinking of doing anything special with the nodes.  If you just
make sure that tiles in areas.list end at 85 (or whatever works) instead
of 90 it will just work, I'd have thought.

> 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)?

I thought that there was a hard limit, but cannot recall my reasons
at the moment.  Anyway you can get errors, sorry can't remember what
they are, but they are due to creating the subdivisions or splitting
the background polygon.  Might be fixable, but the only reason that
you get tiles that large is if they are mostly empty and I'd suggest
trying to avoid too much empty space if you can.

Trying mkgmap on 63240001.osm.gz in your planet split should
demonstrate the problem, and if it doesn't then you can ignore
this :)

> 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,

OK that wasn't a very good description.  There shouldn't be anything
in the database that has a longitude > 180 (although I am sure that
there at least used to be) and so the if the tile ends at 180, the
overlap area will go to 180.02 or whatever and should be empty, so
nothing bad will happen.

> 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?

Very badly I'd expect.

>                             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?

Yes I think it would just work if you did that.

> 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?

Yes you can through away any tile that is empty.  The Computerteddy
maps do that.

..Steve