Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for custom tiling approaches in ndpyramid #92

Open
maxrjones opened this issue Jan 25, 2024 · 3 comments
Open

Support for custom tiling approaches in ndpyramid #92

maxrjones opened this issue Jan 25, 2024 · 3 comments

Comments

@maxrjones
Copy link
Contributor

maxrjones commented Jan 25, 2024

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 2zoom 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 2zoom 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:

  1. Should ndpyramid support the custom tiling scheme? What would be the benefit of this feature?
  2. 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
Copy link
Contributor Author

maxrjones commented Jan 26, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor Author

zarr-developers/geozarr-spec#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant