I found a consistent proj:transform issue in six sampled STAC Items from NRCan's hrdem-lidar collection.
The published proj:transform values appear to be written directly in GDAL GetGeoTransform() order:
[x_origin, pixel_width, x_rotation, y_origin, y_rotation, pixel_height]
The STAC Projection Extension instead defines the six-element transform in row-major affine order:
[a, b, c, d, e, f]
Therefore a GDAL transform g should be reordered as:
[g[1], g[2], g[0], g[4], g[5], g[3]]
rather than stored unchanged.
Affected sampled Items
ON-Upper_Thames_Grand_River_2025-1m
MB-Eastern_Manitoba_2025-1m
SK-SwiftCurrent_FrenchmanRiver_UTM13_2025-1m
SK-SwiftCurrent_FrenchmanRiver_UTM12_2025-1m
MB-Western_Manitoba_2025-1m
QC-600024_51_Bassecotenord_2025-1m
Item endpoint pattern:
https://datacube.services.geo.ca/api/collections/hrdem-lidar/items/
I independently checked the TIFF georeferencing information from the raster assets, including parsing the raw TIFF tags rather than relying only on GDAL's interpreted transform. The raster georeferencing is internally consistent; the contradiction is in the published STAC transform ordering.
Interpreting the published array according to the STAC Projection Extension produces clearly invalid georeferencing — in the sampled case, including an implied pixel size on the order of ~1,000 km and coordinates inconsistent with the Item's own extent.
All six Items show the same issue. I also checked six additional NRCan collections and observed the same ordering pattern, suggesting this may originate in a shared STAC-generation pipeline.
The affected Items currently pass both:
PySTAC 1.14.3 Item / Projection Extension schema validation
stac-check 1.14.0 (ITEM Passed: True)
This appears to be because those checks validate the metadata structure but do not compare proj:transform against the actual raster asset.
The STAC Projection Extension specification also explicitly notes that GDAL GetGeoTransform() values require re-ordering before use as proj:transform.
I can provide the exact declared transforms, TIFF-derived transforms, and a minimal reproduction script if useful.
I found a consistent proj:transform issue in six sampled STAC Items from NRCan's hrdem-lidar collection.
The published proj:transform values appear to be written directly in GDAL GetGeoTransform() order:
[x_origin, pixel_width, x_rotation, y_origin, y_rotation, pixel_height]
The STAC Projection Extension instead defines the six-element transform in row-major affine order:
[a, b, c, d, e, f]
Therefore a GDAL transform g should be reordered as:
[g[1], g[2], g[0], g[4], g[5], g[3]]
rather than stored unchanged.
Affected sampled Items
ON-Upper_Thames_Grand_River_2025-1m
MB-Eastern_Manitoba_2025-1m
SK-SwiftCurrent_FrenchmanRiver_UTM13_2025-1m
SK-SwiftCurrent_FrenchmanRiver_UTM12_2025-1m
MB-Western_Manitoba_2025-1m
QC-600024_51_Bassecotenord_2025-1m
Item endpoint pattern:
https://datacube.services.geo.ca/api/collections/hrdem-lidar/items/
I independently checked the TIFF georeferencing information from the raster assets, including parsing the raw TIFF tags rather than relying only on GDAL's interpreted transform. The raster georeferencing is internally consistent; the contradiction is in the published STAC transform ordering.
Interpreting the published array according to the STAC Projection Extension produces clearly invalid georeferencing — in the sampled case, including an implied pixel size on the order of ~1,000 km and coordinates inconsistent with the Item's own extent.
All six Items show the same issue. I also checked six additional NRCan collections and observed the same ordering pattern, suggesting this may originate in a shared STAC-generation pipeline.
The affected Items currently pass both:
PySTAC 1.14.3 Item / Projection Extension schema validation
stac-check 1.14.0 (ITEM Passed: True)
This appears to be because those checks validate the metadata structure but do not compare proj:transform against the actual raster asset.
The STAC Projection Extension specification also explicitly notes that GDAL GetGeoTransform() values require re-ordering before use as proj:transform.
I can provide the exact declared transforms, TIFF-derived transforms, and a minimal reproduction script if useful.