[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