On 23/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 22, 2007 8:30 PM,  <<a href="mailto:milenko@king-nerd.com">milenko@king-nerd.com</a>> wrote:<br>> What's the disadvantage to just storing the blank tiles?  If my maths are correct, 35,000,000 300byte tiles would be 143,360,000,000 bytes on disc (assuming 4096 byte clusters).  Divide by 1024 and 1024 and 1024 to get GB and I get 
133.51GB.  That doesn't seem like it would be impossible to do.<br><br>Umm, there's 35 million tiles now. However, over the whole world there<br>are going to be on the order of 2^34 (approx 16x10^9) blank tiles,<br>
Think of the sea and everything not mapped yet. 300 bytes per tile is<br>optimistic since you have a directory entry plus an inode for each,<br>plus any slack space in the block. If you take 0.5KB per tile gives<br>you 8x10^9KB or 8000Gigabytes. Add another 35% for all the other zoom
<br>levels puts you at about 11petabytes. And I think that's optimistic.<br><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.</blockquote><div><br>
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... <br><br>Not sure of the hardware, but, given enough RAM, it should be possible to hold the entire thing in RAM as some form of bit array... Obviously, the cost of reading and saving any changes to/from disk would be potentially high, but, something along these lines, with some smart disk access should be able to give a constant level of performance no matter how many blank tiles we store, and that constant performance I would guess would be higher than we currently get from the database...
<br><br>I'd be willing to have a go at this, but, I don't currently have much knowledge of what we have in place, what it's written in, etc... I'd guess someone else who's programming knowledge it more fresh would find this easier, but, I'll try and have a go at doing something anyway...
<br><br>d<br></div><br></div>