AssertionError: Only axis-aligned geoboxes are currently supported

[rsignell-usgs]

I'm relatively new to odc-stac and Digital Earth Africa, and trying out the stac client and odc-stac package to access sentinel-1. I started with the digital earth africa sentinel2 example code and that worked fine, but when I tried adapting it for sentinel-1, I'm getting AssertionError: Only axis-aligned geoboxes are currently supported, despite trying both projected and lon/lat specification.

I'm guessing this is user error rather than a bug, so suggestions welcome! :)

[Kirill888]

It's clearly a bug in odc-stac or possibly datacube. Data sources with non-axis aligned geo references aren't that common so don't get tested as much.

I think this assert is over strict, also not very cheap to run, but it was added 3 years ago...

opendatacube/datacube-core@ca61414

Only some operations are not supported for non-axis aligned geoboxes, but odc-stac is just using it as a container to move geo referencing information around.

[Kirill888]

While this has highlighted an important problem, the real issue is with the projection information in STAC data.

https://explorer.digitalearth.africa/stac/collections/s1_rtc/items/46bbaf19-62fd-58c0-9538-9a48c2aec7cc

    37.0,      0.0002,      0.0,
    13.0,      0.0,      -0.0002,
    0.0,      0.0,      1.0

The order of parameter returned is all messed up, I guess it's using GDAL convention, while stac extension uses row-major, actual files are axis aligned, their transform is:

    0.0002,    0,    37,
    0,    -0.0002,    13,
    0,    0,    1

so, it's a data provider error.

@alexgleith ⬆️ metadata for s1_rtc seems to be broken, I don't think it's to stac conversion issue, looks like it's like that in yaml too.

[Kirill888]

https://explorer.digitalearth.africa/products/s1_rtc/datasets/46bbaf19-62fd-58c0-9538-9a48c2aec7cc

[alexgleith]

Hey @rsignell-usgs thanks for this report.

This is the original metadata, as supplied: https://deafrica-sentinel-1.s3.af-south-1.amazonaws.com/s1_rtc/N12E037/2020/09/02/03F841/s1_rtc_03F841_N12E037_2020_09_02_metadata.json

It has the same order. I'll get Marko from Sinergise to look at the order of the transform parameters.

[alexgleith]

Can I confirm that if we do change the axis order in the transform to what GDAL uses, it'll fix it @Kirill888?

[Kirill888]

So expected order for proj extension is

sx, 0, tx, 
0, sy, ty,
0,  0,  1

flattened: sx,0,tx,0,sy,ty

What appears to be in the metadata is: tx,sx,0,ty,0,sy which I think is gdal geotransform order.

which is different from what it is expected in stac
https://github.com/stac-extensions/projection#projtransform

[Kirill888]

Can I confirm that if we do change the axis order in the transform to what GDAL uses, it'll fix it @Kirill888?

@alexgleith not to but AWAY from what GDAL uses and into matrix form instead, then serialized in row major order as a flat 9 element array
sx,0,tx,0,sy,ty,0,0,1

[alexgleith]

rio info gives me: "transform": [0.0002, 0.0, 37.0, 0.0, -0.0002, 13.0, 0.0, 0.0, 1.0]

Whereas the STAC is [37, 0.0002, 0, 13, 0, -0.0002]

I don't know which is correct, though.

Edit: from your link the Rasterio Transform is correct.

[Kirill888]

stac-extensions/projection#9

[Kirill888]

Same issue in stacstack it seems:

gjoseph92/stackstac#132

[Kirill888]

@rsignell-usgs you can work-around this issue by disabling proj extension for s1_rtc collection with the following config:

config = {
    "s1_rtc": {
        "ignore_proj": True
    }
}

Then you should be able to load the data, but you will have to supply crs= and resolution= parameters as these can not be auto-guessed when proj extension is disabled or not available. But you already do that in your example.

[alexgleith]

FYI this has been acknowledged by the Sentinel-1 suppliers and they are issuing a fix.

[alexgleith]

I believe this has been fixed, for example, here's a newly produced scene: https://explorer.digitalearth.africa/stac/collections/s1_rtc/items/0a461211-1d56-5bb0-8baf-bb9917d8f77f

The transform is:

"proj:transform": [
0.0002,
0,
50,
0,
-0.0002,
12,
0,
0,
1
],