Multiscales zoom level vs decimation

[thomas-maschler]

I'd like to get more clarity on the Multiscales section.

To my understanding, overviews for raster data - including COGs - do not necessarily have to align with standard webmap zoom levels. In fact, for most projections, a direct comparison is not even possible. Depending on the location, tiles in a local projection might fall into different zoom levels or might be wrongly oriented. Mapbox wrote a nice blog post on the various challenges showing raster tiles in non-standard projections on a webmap.

There are only two projections for which standard webmap zoom levels are commonly used. Webmercator projection (epsg:3857) and Plate Carree (epsg:4326). For the first, Zoom level 0 can be represented using a single tile. For the latter, Zoom level 0 can be represented using two tiles. Tiles for the following zoom levels can be derived by creating a quad-tree for each tile in zoom level 0.

While you can theoretically follow a similar approach for other global projections, in practice it often doesn't lend itself very well. In many cases, you would end up with parent tiles being partially outside of the projection's extent and/or some of the child tiles being fully outside, etc.

For Geotiffs and other raster formats, we usually create overviews in decimation of 2^n relative to the base resolution. Such overviews may or may not align with standard webmap zoom levels. We always use the decimation as the descriptor, not the zoom level. (Roughly speaking, higher decimations represent lower zoom levels).

The TMS Specifications summarize these two different approaches quite well in the profile section.

In its current form, the GeoZarr Specifications do not capture well these challenges and assume that overviews are always aligned with webmap zoom levels. To my opinion, this is usually the exception, not the norm.

It is also not clear to me whether it would be allowed to have overviews in a different projection than the base layer. This idea is quite tempting to me. This would allow storing data in a local projection in the base resolution and build overviews using WebMercator for easy viewing. However, varying projections could also cause trouble in cases when users would want to use existing overviews for resampling data.

I'd like to discuss how this issue can be better represented in the specification.

One solution could be to make the level key not mandatory and introduce a mandatory key decimation. Having an additional key indicating the units per pixel would also be valuable in case users choose a decimation that is not a whole number. Naturally, the path should follow the order of the decimation, not of the zoom level. IMO, when not specifying the crs, the projection should default to the projection of the base dataset, not pseudo plate caree.

An example would look like this (red mandatory, green optional)

+{
+  "multiscales": [
-    {
-      "name": "example",
-      "datasets": [
-          {"path": ".",  "decimation": "0",
+           "level": "4", "crs": "EPSG:3857", "units_per_pixel": "64"},
-          {"path": 1, "decimation": "2",
+.          "level": "3", "crs": "EPSG:3857", "units_per_pixel": "128"},
-          {"path": "2", "decimation": "4",
+.          "level": "2", "crs": "EPSG:3857", "units_per_pixel": "256"},
-          {"path": "3", "decimation": "8",
+.           "level": "1", "crs": "EPSG:3857", "units_per_pixel": "512"},
-          {"path": "4",  "decimation": "16",
+           "level": "0", "crs": "EPSG:3857", "units_per_pixel": "1024"}
-      ],
+      "type": "gaussian",
-    }
+  ]
+}

Please note that this suggestion would break the path order of the current specs.
I am curious to hear other people's thoughts on this.

[briannapagan]

Thanks for the thoughts @thomas-maschler - I want to point to work being done by Carbon Plan:
https://github.com/carbonplan/ndpyramid - maybe @maxrjones or @norlandrhagen can also speak to what they have implemented so far for multiscale zarrs.

[maxrjones]

Hey @thomas-maschler and @briannapagan - thanks for the ping and sorry for my slow response! I wrote up https://ndpyramid.readthedocs.io/en/latest/schema.html for some information about the current state of multiscales in ndpyramid and @carbonplan/maps. The two primary generation methods (pyramid_reproject and pyramid_regrid) produce pyramids that align with standard webmap zoom levels. I'll need to look into your point about epsg:4386 being represented as two tiles at zoom level 0 - we represent this as one tile for both epsg:3857 and epsg:4386.

@thomas-maschler on your point about the decimation approach being most common for COGs - we currently exclusively use the webmap zoom levels approach to pyramids under the following assumptions:

1. rendering maps via either a tiling server or dynamic client approach is much quicker if the pyramids follow this structure (see https://github.com/NASA-IMPACT/zarr-visualization-report)
2. given that empty chunks can be not written with Zarr, there is not much extra storage cost to following a webmap zoom level structure relative to a decimation structure (untested, but I'm hoping to evaluate storage differences in the next week)

Do you mind sharing if there's anything that I'm missing here that would motivate supporting both the web-optimized and decimation structure in Zarr? The main counter argument that I'm aware of is having the pyramids be as similar to the raw data as possible, though it's not clear to me whether that's worth the reduced rendering performance in most cases.

[maxrjones]

FYI I just opened carbonplan/ndpyramid#92 to discuss if we should support generating custom tiling schemes and, if so, how it would be represented in the metadata, which touches a bit on this topic. Would love any thoughts you have to share!

[thomas-maschler]

Thanks @maxrjones, if you plan to use the overviews for rendering webmaps your strategy makes sense. However, this is not always the case.

Here are a few use cases for which the zoom level strategy does not apply:

Multi-Scale Analysis:
Users might need to process data at different resolutions and want to keep their source data in one place. Overviews are not optimized for visualization purposes but for storing resampled, analysis-ready data. Overviews might not follow a decimation of 2^n. Instead, they match the common processing resolutions of the user.

Custom projection:
Users want to store their data in a custom projection for which no standard tiling scheme is defined. Users may need to visualize the data in that custom projection and storing overviews in a different projection does not make sense.

Scene data:
Similar to the one above, but agnostic of the projection. Here, data represent a standalone scene and snapping overviews to a standard tiling scheme is not necessary. Instead, users prefer to store data in standard overviews with a decimation of 2^n using the base resolution of the scene as 2^0.

In my initial comment, I mentioned the TMS Specifications, which supports top-down (zoom level) and bottom-up (decimation) profiles.

The WMTS Specification uses an even more flexible approach. The identifier of the level can be any arbitrary string. The resolution is defined by the ScaleDenominator which expresses the cell size as cellSize=scaleDenominator×0.2810−3/metersPerUnit(𝑐𝑟𝑠). Users can reference well known tile matrixes (ie WM. Platte Carree etc) but can also define their own.

These two Specifications are well-established battle proven standards and I think it would be worth leaning on one of those concepts, to support a broad range of use cases.

[forman]

Hi there! We use a very simple spec for multi-resolution Zarrs for efficient visualisations since several years: https://github.com/dcs4cop/xcube/blob/master/docs/source/mldatasets.md

Also here, higher decimations represent lower zoom levels. Basically it is a pyramid created on to of the original dataset at level zero using the original CRS. For visualisation, tailored tile matrix sets using different CRSes are created on-the-fly by the tile server (xcube). For us it is important to not create redundant datasets just for visualisation purposes.