GeoZarr Extension

[jhamman]

In zarr-developers/zarr-specs#124, @christophenoel wrote:

This specification is an early draft (v0.1) and a prototype implementation of GeoZarr-based (and Cloud based) geospatial data store has been demonstrated to the Agency in the frame of the project. We are also developing a map viewer (based on OpenLayers) to demonstrate multiscaling and integration of the store in an Earth Observation catalogue.

Cross posting here as there may be some direct overlap with the specification we're using in ndpyramid and @carbonplan/maps.

@christophenoel - if you have some time to expand on your multi-scale specification, I'd be very interested to hear more.

Multiscale: I used draft 50 ideas as a baseline. It was migrated to image.sc but misses the geospatial aspects. From my point of view, resolution property is relevant for geospatial data to ease the computation of the scale according to zoom level (instead of computing the value from the coordinates variables)

For reference, we're also basing our specification off the image.sc draft, with some specific tuning to support our mapping applications.

[christophenoel]

Dear Joe,

Thank you very much for your comments. I didn't know that there is an existing Zarr support in a map viewer.

I believe that you're the expert for this aspect, so I would be interested to know how you infer the correct scale to use depending on the current zoom. Don't you compute the current resolution ?

Is there a document specifying the assumptions on Zarr data ?

THanks.

[jhamman]

Thank you very much for your comments. I didn't know that there is an existing Zarr support in a map viewer.

You may find this interesting then: https://carbonplan.org/blog/maps-library-release

I believe that you're the expert for this aspect, so I would be interested to know how you infer the correct scale to use depending on the current zoom. Don't you compute the current resolution ?

We generate data in zarr format for various zoom levels based on a quad tree layout. Level 0 is a single tile the represents the full Web Mercator extent in a single tile (e.g. 128x128). Each level is written as a different group in the zarr dataset and we pull data into the client based on the current zoom level. So, we compute the zoom level (Mapbox helps here) and we pull the corresponding data based on that.

Is there a document specifying the assumptions on Zarr data ?

Not yet. But we can write this up.

@freeman-lab and @katamartin may have more to add here.

[christophenoel]

Thanks, very interesting.

This is not a criticism, but by default, I would rather favour the more popular zoom levels used for example by XYZ tiling (https://wiki.openstreetmap.org/wiki/Zoom_levels) , and also ArcGIS (https://developers.arcgis.com/documentation/mapping-apis-and-services/reference/zoom-levels-and-scale/) .

However, the resolution indicator would allow to suits any convention. What do you think ?

[freeman-lab]

Hi @christophenoel , can you maybe say more about what you mean by "more popular zoom levels"? Our understanding is that the OSM / Mapbox zoom levels are essentially the same as one another and the same as what we're using here. It's true that, in a typical map tile server, tiles would be stored with a {z}/{x}/{y}.png naming pattern, whereas here we have a separate {z} array for each zoom level, and then individual chunks are {y}.{x}, per the conventions of zarr-python. Is that what you mean by the difference?

[christophenoel]

According to your table, latitude at equator is 78271.484 meters/pixel for zoom 0 while the de facto standard used by OSM, ArcGis, OpenLayers is twice the resolution 156 412 meters / pixel (they consider zoom level for 256x256 pixels tiles).

[christophenoel]

(however, I suppose that the difference by a factor 2 is not significant, and the map user doesn't really see any difference).