Use as custom Mapbox layer (without regl)

[carderne]

I've been playing around a bit with this code to see how feasible it would be to use most of the pipeline to create a custom Mapbox WebGL layer rather than a completely separate canvas rendered underneath a Mapbox layer.

The advantage of this (to my mind) would be that you could more easily interleave zarr layers with Mapbox layers, control visibility/opacity together with Mapbox, and potentially more easily build it out as a library rather than a framework as it currently is?

Would need to pull out regl, as afaict it doesn't support WebGL2 (which Mapbox requires).

I'm going to keep tinkering, but I thought I'd share this idea as I barely know my way around WebGL so may take a while!

[carderne]

For what it's worth, I have this working here:

https://github.com/carderne/zarr-gl

It's very basic currently, but I plan to add most of the missing functionality soon (and make it less janky!).

[Shane98c]

This is so cool to see!

Another pain point that this potentially helps with is escaping web mercator - it seems like custom layers might be able to render on mapbox's globe view (tho not their other projections for the moment)? Maplibre has a globe view coming as well so it'll be interesting to see whether custom layers are supported there too!

We've had something like this on our maps bucketlist for a while but haven't had capacity to iterate on this project (as you can maybe tell from our issues page!). It's so exciting to see such quick progress on this - we'd love to figure out how to help out! Some initial thoughts:

• We were able to get regl working with webgl2 with some tricks here: webgl2 #126
• We've been meaning to try using zarrita.js instead of zarr-js because the former is better maintained and likely to become the official zarr JS client.
• We've also played with the idea of using webgl to render out z/x/y raster tiles from zarr on the client (basically client side titiler) which would get us more flexibility with projections/mapping libraries but probably at the expense of performance/smoothness

We're very excited to keep playing with zarr-gl and to see how it progresses. Thanks for reaching out!

[carderne]

Hey @Shane98c thanks for this!

• Custom layers in Mapbox Globe: found that same thread, haven't yet investigated how it might work. Docs suggest that the data still needs to be in mercator coordinates...

• Regl with webgl2l: yeah I noticed just a bit too late that you'd figured that out. I haven't really used WebGL enough to know what I'm missing out by not using regl, but zarr-gl is still very little code so I figure not too much?

• Zarrita: I actually switched back to zarr-js temporarily because the build output had all the blosc/lz4 stuff lumped in and wanted to figure out what was going on there before sticking with it. Haven't done any performance comparisons but presumably minimal. Definitely types are nice.

• Projecting on the client: I started googling about this, bunch of interesting stuff from Bostock. Maybe some Rust decompression + zarr + reprojecting compiled to WASM would make this feasible, don't have a great grasp of the order of magnitude of performance hit... This would be amazing though.

Anyway I'm going to keep slowly noodling. I need to add support for selector and improve the logic around choosing tiles to load/retain, and then it should be relatively useable.

[carderne]

Oh and the other reason I switched back from zarrita: it seems to have some important metadata as private class fields. Haven't yet reached out to the devs to properly understand this.

[manzt]

Oh and the other reason I switched back from zarrita: it seems to have some important metadata as private class fields. Haven't yet reached out to the devs to properly understand this.

hey! zarrita author here. A goal in zarrita is to have consistent client APIs, regardless of how the Zarr source is encoded (either v2 or v3). As such, I've intentionally put some metadata behind private class fields to keep encapsulation, selectively exposing consistent APIs for various fields. If there is metadata that you require and we are missing APIs for, we should add it. Let me know!

[carderne]

Hey @manzt sorry for the slow reply. I haven't looked at this code for a while, but would love to switch it over to zarrita.

My full code (adapted from a file in this carbonplan/maps repo) is in this file:
https://github.com/carderne/zarr-gl/blob/main/src/store.ts#L101

Relevant bits (ignoring v2 for now):

Getting metadata

const metadata = await fetch(`${source}/zarr.json`).then((res) => res.json());
const multiscales = metadata.attributes.multiscales;
const datasets = multiscales[0]?.datasets;
const levels = datasets.map((dataset) => dataset.path);
const tileSize = datasets[0]?.pixels_per_tile;
const crs = datasets[0]?.crs;

Array metadata

const arrayMetadata = await fetch(`${source}/${levels[0]}/${variable}/zarr.json`).then((res) => res.json());
const dimensions = arrayMetadata.attributes._ARRAY_DIMENSIONS;
const shape = arrayMetadata.shape;
const isSharded = arrayMetadata.codecs[0].name == "sharding_indexed";
const chunks = isSharded ? arrayMetadata.codecs[0].configuration.chunk_shape : arrayMetadata.chunk_grid.configuration.chunk_shape;
const fillValue = arrayMetadata.fill_value;

Are you able to tell at a glance which of those are/aren't exposed in zarrita? If not I'll start the conversion to zarrita again and I can let you know where I get stuck.