[mkgmap-dev] bugreport for new splitter

Mon Aug 10 13:20:46 BST 2009

> Well I'm just saying that there was no particular thought in choosing
> 2000 in the first place.

I see. Obviously 2000 can't be working too badly since otherwise I'd assume 
more people would have complained by now :)

> For really old devices that have limited memory you may only be able
> to load a few tiles at a time and then it would be more flexible to
> have smaller tiles.  But this is really from before OSM was started,
> I've never had anyone complain that tiles were too big, in fact quite
> the opposite.
>
> So ideally you want to be able to make the tiles as large as possible.
> However if you only look at the number of nodes then you find that
> you have to have it quite low to cope with one particular area
> when a higher value would have been fine everywhere else.
> ..Steve

Thanks for the explanation. Is there anywhere you know of where I can read 
more about what the known limits on tile sizes/content/quantities are? I've 
seen various comments about a 2025 map segment limit (is a map segment the 
same as a map tile?), a 2048MB limit (due to 32 bit indexing in the file 
format and/or file system?) on forums like these:

http://garminoregon.wikispaces.com/message/view/home/10590340
http://forums.groundspeak.com/GC/index.php?showtopic=170615&st=54#

But it's still not completely clear to me what's going on. In particular, 
what determines the maximum tile size? You're saying it's not the number 
of nodes, but perhaps the number of ways? Or is it even more complex than 
that, ie a factor of the node/way/relation count combined with the number 
of nodes per way and/or complexity of the ways?

If the exact criteria was known then maybe we can come up with a better approach 
to choosing the area boundaries to split on.

Thanks,
Chris