On 24/12/2007, <b class="gmail_sendername">Martijn van Oosterhout</b> <<a href="mailto:kleptog@gmail.com">kleptog@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Dec 23, 2007 7:21 PM, D Tucny <<a href="mailto:d@tucny.com">d@tucny.com</a>> wrote:<br>> On 23/12/2007, Martijn van Oosterhout <<a href="mailto:kleptog@gmail.com">kleptog@gmail.com</a>> wrote:<br>> > The whole point of the exercise is to not store all those. Doesn't
<br>> > really matter how, just need to find a way.<br>><br>>  With 18 zoom levels (0-17) and a single layer, we get a total of approx 23<br>> billion tiles... If all we are going to store all of them as land or sea,
<br>> the most efficient (storage wise, not speed wise and ignoring compression)<br>> way we could store them would be a single set of sequential bits, that would<br>> come out as about 2.7GiB...<br><br>You need at least three states, (LAND/SEA/TILE) so I'd suggest you
<br>look at the code supporting the oceantiles_12.dat file which does<br>exactly this. Not everybody likes it though. An SQL table has the huge<br>advantage of being easily accessable with standard tools...</blockquote><div>
<br>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...<br>
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... <br>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...
<br><br>d<br></div><br></div>