Support for custom tiling approaches in ndpyramid

maxrjones commented 8 months ago

Overview of tiling schemes in ndpyramid

Most of the CarbonPlan mapping toolkit is based on the map zoom level quadtree pattern where the number of tiles at a given zoom level corresponds to 2^zoom and each zoom level covers the entire globe, as described in the schema docs. ndpyramid currently supports EPSG:4326 and EPSG:3857 through the pyramid_reproject and pyramid_regrid functions, which correspond to the global-geodetic and global-mercator profiles in the Tile Map Service OGC Specification, with the exception that the EPSG:4326 pyramids have one tile at zoom level 0, whereas the global-geodetic profile has two.

The pyramid_coarsen function instead generates pyramids with each zoom level representing a decimation relative to the base resolution. In the case in which each zoom level is a decimation of 2^zoom relative to the base resolution, this corresponds to the local profile in the Tile Map Service OGC Specification. These pyramid levels do not align with standard web map zoom levels, can be in any projection, and are not supported by @carbonplan/maps.

The gdal COG driver also supports a custom tiling scheme, which allows setting the target projection, resolution, and extent independently. This is not currently supported in ndpyramid.

Open questions:

Should ndpyramid support the custom tiling scheme? What would be the benefit of this feature?
Would there be substantial benefits of @carbonplan/maps supporting a local or decimation pyramid scheme?

A separate issue is how to best represent the difference between these schemes in the multiscales metadata. Currently the representation would need to be inferred by the method and kwargs attributes, which seems difficult to interpret.

Benefits of global tiling scheme

More performant rendering, especially when in Web Mercator

Benefits of local tiling scheme

Cost savings for storage. For example, this notebook shows that the global-geodetic tiling scheme produces pyramids for the CORDEX model that are ~22% or ~190% larger than the local scheme depending on whether the upper or lower zoom level determination is used. I expect the difference is larger for higher resolution data with smaller spatial extents.
Keeping the data as close to the raw format as possible (so you don't have any reprojection resampling)

maxrjones commented 8 months ago

FYI @katamartin and @freeman-lab on this issue following-up on our zoom discussion. I think the storage differences between the local and global schemes are interesting to keep in mind, but may not be a major consideration for smaller projects.

maxrjones commented 8 months ago

Vincent Sarago suggested that we should follow the OGC TMS 2.0 standard. A key difference so far is that ndpyramid's EPSG:4326 reprojection produces one tile at zoom level 0 rather than two as defined in the World CRS 84 Quad.

maxrjones commented 6 months ago

https://github.com/zarr-developers/geozarr-spec/pull/44 details how the TMS 2.0 standard could be used in GeoZarr. It would be great to test out that approach in ndpyramid, and discuss the implications for carbonplan/maps.

carbonplan / ndpyramid