[OSM-dev] Quadtile Info and Planet dump

Brett Henderson brett at bretth.com
Sun Sep 23 04:26:39 BST 2007

Martijn van Oosterhout wrote:
> You're only talking about the client. What about:
> a) Extra time in the sprintf in the planet dumper, on the server
> b) Extra time to compress the result, on the server
> c) Extra time storing said data on disk, on the server
> d) Extra time transferring it over the network to your machine, from the server
> When you add all these to your option b, the current setup doesn't
> look so bad anymore... Especially since 99% of people will never use
> it.
> Have a nice day,
I agree.  I'd be extremely wary about adding information like this to 
the planet file.  The tile column supports a special form of indexing 
requiring some application level support to function, it is not really 
part of the data model.  In effect we've moved some of the job of 
indexing out of the database server into application code.  This is not 
a bad thing because the results have spoken for themselves, but I 
wouldn't want to see tile information spread too far through the OSM 
toolchain.  Next week we may decide to change the tile granularity, find 
an even more effective way of indexing the database, or perhaps even 
decide to use a new database server implementation.  If we let tile 
information outside of the database it will become a burden we have to 
support on an ongoing basis.

Given that the tile information can be re-calculated from lat lon anyway 
and at a granularity/zoom level that suits the end purpose instead of a 
granularity that suits indexing there shouldn't be a problem.  I'd be 
surprised if the performance hit is terribly large.  But I'm about to 
add tile calculation code to osmosis and will try to get some numbers 
during the next week.

More information about the dev mailing list