Support CRSes defined as WKT strings

[jeremyh]

In the spatial_reference field cubedash currently supports either EPSG codes or a custom format used by NEMO’s old scenes.

The new Sentinel products define their spatial references as WKT strings.

This may be non-trivial as all crs handling is currently done within Postgis, and it doesn’t appear to have any methods for translation between CRS formats (other than an exact string match on an existing registered CRS, which won’t match any Sentinel datasets).

We might need to add an extra step during summary generation to scan all datasets to find unique CRSes and translate them within Python, registering the result with Postgis. ... and then do an exact string match.

[whatnick]

Can this be closed with partial support from #127

[palmoreck]

Hi everyone. First thanks for this awesome explorer for datacube.

I have deployed successfully the explorer but don't know why a product is not correctly displayed as referred here CONABIO/kube_sipecam#14 (comment)

As you can see in that comment my srtm_cgiar_mosaic product is correctly displayed but not my ls8_espa_scene and don't know what's the reason. I'm thinking that is related with CRS but srtm_cgiar_mosaic and ls8_espa_scene have the same one as you can see in:

ingestion/srtm_cgiar_mexico.yaml#L28

ingestion/ls8_espa_mexico.yaml#L33

Thanks in advance.

Cheers

[jeremyh]

Hey @palmoreck! The trouble with WKT strings like this is that Explorer is reliant on Postgis knowing the CRS already, which are registered in Postgis's spatial_ref_sys table. It doesn't look like Postgis ships by default with those CRSes so it's not able to understand them.

One option is to run the relevant "PostGIS spatial_ref_sys insert statement"s on spatial-ref.org to register them with Postgis: https://spatialreference.org/ref/sr-org/mexico-inegi-lambert-conformal-conic/

... then you can use the <auth_name>:<srid> from that statement ('sr-org:6700' in this case), or the WKT itself, in your yaml files.

... but the WKT will only work if it matches exactly, unfortunately, as a string. Or if it ends with an AUTHORITY[]] tag containing the auth_name/srid that Explorer can extract.

... and another gotcha is that using sr-org:6700 alone may confuse gdal, which datacube itself uses to understand the crs.

It's a slightly messy situation at the moment unfortunately.

[jeremyh]

This is definitely something we could improve in Explorer.

Maybe:

• Add a "register new crs" command-line tool to make it easier to register them. (It could even read them from existing yaml files?)
• Improve the error message shown to users, even if it's just a link to this Github issue.

[palmoreck]

Hi @jeremyh thank you for your answers.

Ok. If using EPSG:4326 solves this troubles then I'll use it. In fact in my workflows I've been thinking using this because at the end I'm reprojecting to this CRS for sharing my maps with colleagues.

Greetings!

[jeremyh]

Leaving open -- it's still something to improve.

We want to support all data that ODC itself supports, preferably without extra hassle.

[omad]

While this does sound potentially useful, I'm going to close this to save our backlog growing indefinitely.

It is something we could do, but there's a strong case to be made that it isn't something we necessarily should.

There's work taking place in ODC Core to make greater use of PostGIS tables and features, which would be a more appropriate place for this to be addressed if and when it comes up again.