Copernicus DEM data available on AWS

While adding support for Copernicus DEM, we also copied the data to AWS, in Cloud Optimized GeoTIFF file format.

More info here https://registry.opendata.aws/copernicus-dem/.

Is there a document that explains about the metadata for these Copernicus DEM tiles in Cloud-Optimized GeoTIFF (COG) format? I downloaded a few tiles of the GLO-30 data, and I see that the tiles near the equator are 3600 by 3600 pixels, but the original Copernicus DEM data described in their data handbook says the one-degree tiles are 3601 by 3601 pixels. The original Copernicus DEM has data sampled on the even degree (center of first pixel), so the last pixel is also on the even degree after 3601 pixels. Did you remove one column and one row of the data to create the COG tiles or did you resample the data so the center of the pixels is shifted by half a pixel from the even degree and the top left corner of the top left pixel is on the even degree? If you did remove a column and row from each tile, was it on the north, south, east or west edges? Either way, the metadata included in the GeoTIFF files does not seem to be correct.

This is the report from gdalinfo on one of your GeoTIFF files:

Driver: GTiff/GeoTIFF
Files: tiles/Copernicus_DSM_COG_10_S14_00_W172_00_DEM.tif
Size is 3600, 3600
Coordinate System is:
GEOGCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    ID["EPSG",4326]]
Data axis to CRS axis mapping: 2,1
Origin = (-172.000138888888898,-12.999861111111111)
Pixel Size = (0.000277777777778,-0.000277777777778)
Metadata:
  AREA_OR_POINT=Point
Image Structure Metadata:
  COMPRESSION=DEFLATE
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-172.0001389, -12.9998611) (172d 0' 0.50"W, 12d59'59.50"S)
Lower Left  (-172.0001389, -13.9998611) (172d 0' 0.50"W, 13d59'59.50"S)
Upper Right (-171.0001389, -12.9998611) (171d 0' 0.50"W, 12d59'59.50"S)
Lower Right (-171.0001389, -13.9998611) (171d 0' 0.50"W, 13d59'59.50"S)
Center      (-171.5001389, -13.4998611) (171d30' 0.50"W, 13d29'59.50"S)
Band 1 Block=1024x1024 Type=Float32, ColorInterp=Gray
  Overviews: 1800x1800, 900x900, 450x450

By comparing the Copernicus GLO-30 DEM from your AWS S3 bucket to a tile of NASADEM (reprocessed SRTM), it appears that your data has been resampled to have the center of the pixel shifted and the top left corner of the top left pixel on the even degree. After adjusting the metadata so that the DEM better matches the NASADEM, I think this may be the correct location:

Driver: GTiff/GeoTIFF
Files: bothShiftTiles/Copernicus_DSM_COG_10_S14_00_W172_00_DEM.tif
Size is 3600, 3600
Coordinate System is:
GEOGCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    ID["EPSG",4326]]
Data axis to CRS axis mapping: 2,1
Origin = (-172.000000000000000,-13.000000000000000)
Pixel Size = (0.000277777777778,-0.000277777777778)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-172.0000000, -13.0000000) (172d 0' 0.00"W, 13d 0' 0.00"S)
Lower Left  (-172.0000000, -14.0000000) (172d 0' 0.00"W, 14d 0' 0.00"S)
Upper Right (-171.0000000, -13.0000000) (171d 0' 0.00"W, 13d 0' 0.00"S)
Lower Right (-171.0000000, -14.0000000) (171d 0' 0.00"W, 14d 0' 0.00"S)
Center      (-171.5000000, -13.5000000) (171d30' 0.00"W, 13d30' 0.00"S)
Band 1 Block=3600x1 Type=Float32, ColorInterp=Gray

Thanks,
++Eric

Hi Eric,

We do have documentation here https://copernicus-dem-30m.s3.amazonaws.com/readme.html, which is also linked in Registry of Open Data on AWS https://registry.opendata.aws/copernicus-dem/, but it doesn’t say how we created tiles. I will explain it here and will add the explanation to documentation.

Original tiles share one row or column with a neighboring tile, and have sizes such as 3601 by 3601 pixels, 2401 by 2401 pixels, 1801 by 1801 pixels, or something else, depending on the longitude. We removed these shared rows and columns on east and south edges to got the dimensions that are nicely divisible by two, and this enabled us to create nice COG overviews.

We did not resampled the data and the centers of the top left pixels are still on the even degree. Isn’t this confirmed by your output, as it says that the origin (the top left corner of the top left pixel) is away from the even degree in north and west direction by half a pixel, and so the center of the pixel is then on the even degree?

Thanks for your reply. I think I understand now that you keep the top left pixel center on the even degree, but the bottom right pixel center is actually 1-arcsecond northwest of the even degree because you removed the southernmost row and the eastermost column of the tile.

That’s right - this is the reason why the bottom right pixel center is away from the even degree.

This removal of the southernmost row also means that the data in the file does not actually reach the even degree at the southwest corner of the tile that is used for the file name, so I think that would be helpful to include in the readme.

I agree and will make sure this is included in the readme.

I hope the updated readme now clarifies this.

Does the GLO-90 and GLO-30 Copernicus DEM data that is available on AWS have a vertical reference datum applied? And if so, is it the EGM2008 geoid (EPSG 3855)?

It has and it’s EGM2008.

Thanks for validating that info.