One thing I've wondered about are size savings for DEM tiles. Typically elevation values are encoded in RGB values giving a resolution down to fractions of an inch [1]. This seems like overkill. With an elevation range from 0 - 8848 meters (Mt everest), you can use just 2 bytes and get an accuracy down to .2 meters. That seems plenty for many uses. Does anybody know if there's a PNG16 format where you can reduce the file size by only using 2 bytes per pixel, instead of the typical 3-byte RGB or 4-byte RGBA?<p>[1] <a href="https://docs.mapbox.com/data/tilesets/guides/access-elevation-data/#decode-data" rel="nofollow">https://docs.mapbox.com/data/tilesets/guides/access-elevatio...</a>
> Instead of serving a 256x256px image, you can serve a 1px image and tell the browser to scale it up. Of course, if you have to put width= "256px" height= "256px" into your HTML that adds 30 bytes to your HTML!<p>CSS is a thing as well, could just use CSS to force all tiles to the same size, regardless of the image data in them. Something like:<p><pre><code> .map img {
width: 256px;
height: 256px;
}</code></pre>
Was new to me, but it seems "slippy map" is open-streetmap's terminology for a generic zoomable-pannable web map view, here used to refer to any such UI - whether backed by OSM or google or bing or whoever's map data.<p>Feels like a weird word choice to me, when 'map' was right there, but who are we to judge.
I love image formats and data packing, but was disappointed that the reveal was that maps use raster tiles. The map data is vector, why not render it as such?
Seems a lot more performant to generate single color images programatically rather than sending it over the wire?<p>Assuming this level of optimization is actually warranted
The difference between the OSM and Google tile is 75 bytes. So if they serve one million tiles OSM saved 75MB.<p>OSM needs 54TB for all tiles but only around 1.8% are viewed. So you need at least 1TB of cache.<p>I am curious if this micro optimalization really makes a difference.
This is one example where "zopfli" or other optimized zlib compressors don't help, the input data is too simple.<p>"oxipng" (my current preferred png optimizer) bring a plain 256x256 image created with imagemagick down to 179 bytes, as long as you tell it to strip all metadata objects.<p>Interlacing doesn't make any difference, it's the same size with it on or off.
gzip compressed (binary) pbm is only 56 bytes; 32 bytes for zstd compressed data. PBMs have a very simple header and no footer, so the file is almost entirely all zeroes.
Anyone else sometimes find it hard to upvote? [1]<p>[1] <a href="https://files.littlebird.com.au/Shared-Image-2022-04-22-17-52-37.png" rel="nofollow">https://files.littlebird.com.au/Shared-Image-2022-04-22-17-5...</a>