Sampling Copernicus DEM

[scottyhq]

I think it would be useful to add the Copernicus DEM as a raster dataset that can be sampled:
(https://github.com/SlideRuleEarth/sliderule/blob/main/packages/core/extensions/earth_data_query.lua)

This VRT is references the original data with geoid heights:
https://opentopography.s3.sdsc.edu/raster/COP30/COP30_hh.vrt

The recommended PROJ pipeline to transform to EPSG:7912 (https://uw-cryo.github.io/3D_CRS_Transformation_Resources/cop30/) is

+proj=pipeline
      +step +proj=axisswap +order=2,1
      +step +proj=unitconvert +xy_in=deg +xy_out=rad
      +step +proj=vgridshift +grids=us_nga_egm08_25.tif +multiplier=1
      +step +proj=cart +ellps=WGS84
      +step +proj=helmert +x=-0.0024 +y=0.0016 +z=0.0232 +rx=-0.00027 +ry=0.00027
            +rz=-0.00038 +s=0.00208 +dx=-0.0001 +dy=-0.0001 +dz=0.0018 +drx=0 +dry=0
            +drz=0 +ds=-8e-05 +t_epoch=2005 +convention=coordinate_frame
      +step +inv +proj=cart +ellps=WGS84
      +step +proj=unitconvert +xy_in=rad +xy_out=deg
      +step +proj=axisswap +order=2,1

cc @bessoh2

[elidwa]

Implemented in #574

The recommended transformation pipeline was not used because SlideRule-supported source data products may be provided in EPSG:7912, EPSG:9989_EGM08, or EPSG:9989, rather than exclusively in EPSG:7912. To ensure consistent vertical handling across all supported inputs, the target CRS was overridden from EPSG:4326 to the compound CRS EPSG:4326+3855, allowing PROJ to apply the appropriate vertical transformations and grid corrections as needed.

[dshean]

Thanks for the update. This should work for vertical datum handling, but wondering if we should be using a specific definition for the WGS84 realization (e.g., EPSG:9055) instead of EPSG:4326 for horizontal CRS? See the Warning here: https://uw-cryo.github.io/3D_CRS_Transformation_Resources/cop30/

[elidwa]

Thank you for pointing it out @dshean. I corrected the code and now the target CRS is being set as target.SetFromUserInput("EPSG:9055+3855");

[bessoh2]

What do you all think about using FABDEM instead of Copernicus? It has buildings and canopy cover removed via an ML algorithm. Either product (Copernicus 30 m and FABDEM) has reported >1 meter of vertical error, but FABDEM should have higher ground surface accuracy in the forest. I did test both Copernicus and FABDEM by sampling at ATL06-SR locations and transforming to the native epsg:7912 of the ATL06-SR, and the differences from the sampled 3dep.values were on the same order as the errors described in the paper linked above, which we concluded was too much uncertainty for snow depth calculations.

[elidwa]

We should discuss it with @jpswinski

[elidwa]

I looked into FABDEM availability from a SlideRule perspective.

The only official location I could find is the University of Bristol data repository:
https://data.bris.ac.uk/data/dataset/s5hqmjcdj8yo2ibzi9b4ew3sn

This is an academic archival site. It is very slow and intended for one-time downloads, not real-time or cloud-native access. The data is distributed as large ZIP archives plus a GeoJSON index, which means SlideRule cannot automatically pull tiles on demand.

The full dataset is about 300 GiB.

I talked to @jpswinski about this. If @dshean and the group (@scottyhq @bessoh2) decide hosting FABDEM makes sense, it can be done.

Questions for the group:

1. Does anyone know of an existing real-time or cloud-native hosting location for FABDEM?
2. If not, do we want to host it ourselves, given the dataset size?