5 ms·

Great points. Thank you for the links. The one trade off here is that uncompressed blobs will require longer downloads than PNG and I think usually the network

Great points. Thank you for the links. The one trade off here is that uncompressed blobs will require longer downloads than PNG and I think usually the network transfer is slower than PNG decoding. But maybe the sample gist takes a Tiff blob and encodes it to a PNG on the client and then maplibre decodes the PNG to canvas. That would be quite inefficient if that's what it's doing.

blacha 3y ago
Those comments were more at pastmaps. For elevation data, we store our DEM/DSM in S3 as LERC [1] COGS, LERC has a WASM bundle which I think can be used in the browser. We found LERC COGs to be one of the most space efficient ways of storing highresolution DEM/DSM data [2], If you wanted to you could fetch LERC tiles directly out of a remote COG and use that directly for the terrain heights. I am more focused on storage/archiving/publishing of our LiDAR capture program [3] than web based visualizations of it though, so I am unsure if a LERC COG would even be better for you than a PNG TerrainRGB. [1] https://www.npmjs.com/package/lerc https://www.npmjs.com/package/lerc [2] https://github.com/linz/elevation/tree/master/docs/tiff-compression https://github.com/linz/elevation/tree/master/docs/tiff-comp... [3] https://linz.maps.arcgis.com/apps/MapSeries/index.html?appid=2552c3a5cee24f7b87806b085c3fee8a https://linz.maps.arcgis.com/apps/MapSeries/index.html?appid...
- Pabloski80 3y ago
  WASM surely could be an improvement over js, especially for kind of BigData-ish/repetitive jobs, and where load on clients might become the next wall after we optimized the cloud/server part, or when we try to use js on cloud leafnodes.