Great visualization and approach with compressing the tile data. Do you have a comparison of how much smaller the payload ends up being compared to simply sending PNG files?
I use PNGs to encode elevation data in my 3D mapping library (https://github.com/felixpalmer/procedural-gl-js/) and this does a pretty good job of compressing the data, for example in the ocean the PNG files are also very small as the image is mostly black. Different use case I now as your data is much more sparse, but I wonder how close the PNG compression would be compared to your approach.
I don't have the exact size comparison between this approach vs PNG compression, but i guess the difference would be similar to the difference between DEFLATE vs brotli.
I'm curious about what you just asked of me though, i will make the actual measurements, and will update this page with the results when i got time.
Great thanks - perhaps obvious, but worth running the PNGs through something like pngcrush.
I'm thinking about it the other way also, that is could your approach be used to reduce the size of DEMs encoded as PNGs. While I can see brotli being more efficient, by not using a image compression algorithm you perhaps lose out on exploiting the 2D nature of the data, as if I understood correctly when you're compressing the data you treat the tile as a 1D blob of binary data.
I use PNGs to encode elevation data in my 3D mapping library (https://github.com/felixpalmer/procedural-gl-js/) and this does a pretty good job of compressing the data, for example in the ocean the PNG files are also very small as the image is mostly black. Different use case I now as your data is much more sparse, but I wonder how close the PNG compression would be compared to your approach.