On 24/12/2007, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > > On Dec 23, 2007 7:21 PM, D Tucny <[EMAIL PROTECTED]> wrote: > > On 23/12/2007, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > > > The whole point of the exercise is to not store all those. Doesn't > > > really matter how, just need to find a way. > > > > With 18 zoom levels (0-17) and a single layer, we get a total of approx > 23 > > billion tiles... If all we are going to store all of them as land or > sea, > > the most efficient (storage wise, not speed wise and ignoring > compression) > > way we could store them would be a single set of sequential bits, that > would > > come out as about 2.7GiB... > > You need at least three states, (LAND/SEA/TILE) so I'd suggest you > look at the code supporting the oceantiles_12.dat file which does > exactly this. Not everybody likes it though. An SQL table has the huge > advantage of being easily accessable with standard tools...
Do we need the 'tile' state? This is fall back, if a tile is marked as land or sea, but we serve a tile from the filesystem, it makes no difference... Having a third state doubles our storage requirements... We do need the ability to support every zoom level I guess though, the data required for up to zoom 17 is 1024x the amount needed for up to zoom 12 or 1365x zoom 12 only which mixes things up a little... Advantages and disadvantages with any approach... Right now the disadvantage we're talking about is that an SQL tables can't keep up with the growth of the data, so, the advantage of a single SQL table being easier to use is soon going to be outweighed by the disadvantage of the failing performance... d
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
