[OSM-dev] tiles at home disk usage
Martijn van Oosterhout
kleptog at gmail.com
Thu May 3 09:22:11 BST 2007
On 5/3/07, Lars Aronsson <lars at aronsson.se> wrote:
> Robert Hart wrote:
> > erm. so the 2 bits per tile at level-12 file, "oceantiles_12.dat" that
> > takes 4,194,304 bytes is more optimal than the 159,179 byte
> > "oceantiles_12.png" file that contains the same information?
> > Surely we could at very least run-length encode the data?
> That's exactly what the PNG format does, and does very well.
> Just use libpng as the API to read and modify individual pixels,
> and all will be fine. Abandon that huge .dat file.
Hmm, my reading suggests PNG uses zlib, not run length encoding.
However, it may allow you to access scanlines individually *if* the
program that wrote the file forces it (in other words, with maximum
compression enabled I doubt it would work).
You still have the problem where changing a single pixel requires you
to write out the whole file. I would be curious to see how programs
handle a 131072x131072 image (for zoom-17), I notice several
vulnerabilites have been found with large images, we might pick up
some whacky bugs in the process :)
Have a nice day,
Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/
More information about the dev