Kyle Barron

@zakjan I'd love your feedback on this 😄

> I think it's important that multi-step loading is designed as an optional enhancement of a simpler single-step loading, so that simpler single-step can be implemented first for a new...

> Any comments on the approach above? [#1140 (comment)](https://github.com/visgl/loaders.gl/issues/1140#issuecomment-855042176) So for a COG it could be something like ### Advanced option: ```js const metadata = await load(geotiffUrl, GeoTiffMetadataLoader) // Load...

> do you think that it could be used in a similar way, by providing URL only to TileLayer? I think we'd want a separate issue to really get into...

Yes, it makes sense to incubate such a tile layer within deck.gl-community. I think the main key is you'd need a common denominator to describe an arbitrary tiling structure from...

Hey @rabernat, happy to see you in this neck of the Github woods! I think Zarr is a good fit for a new loader. I would expect it would be...

> This is probably much too big for interactive browser-based visualization. One question is whether the compression algorithm applied to each block supports streaming decompression. For example if you use...

In order to work with existing Zarr stores with a large block size, you could also take a more server-side approach where you write something like a [rio-tiler](https://github.com/cogeotiff/rio-tiler) adapter for...

> Dynamic rechunking is definitely needed in the Zarr ecosystem. Simple server-side rechunking should be possible with [xpublish](https://medium.com/pangeo/xpublish-ff788f900bbf). This is straying a bit from loaders.gl, but I wanted to add...

> swapping compression on the server, e.g. from lossless to lossy. Aside: could be interesting to test out [LERC](https://github.com/Esri/lerc) with some Zarr data. Seems a good candidate for compressing data...