Extent extraction is broken for datasets using Geographic CRSs

[Kirill888]

Expected behaviour

Should be able to define Dataset grid_spatial with Geographic CRS, like EPSG:4326 using latitude/longitude keys instead of y,x for for geo_ref_points construct:

'grid_spatial': {'projection': {
'spatial_reference': 'EPSG:4326',
'geo_ref_points': {
    'll': {'latitude': 3.9118399999999993, 'longitude': -71.8432},
    'lr': {'latitude': 3.9118399999999993, 'longitude': -70.84252},
    'ul': {'latitude': 4.912519999999999, 'longitude': -71.8432},
    'ur': {'latitude': 4.912519999999999, 'longitude': -70.84252}},
   }}

Actual behaviour

Fails with KeyError in here:

https://github.com/opendatacube/datacube-core/blob/a82de5c031d711043b5dedbb09b609de0d544a4f/datacube/model/init.py#L273-L274

[omad]

I think the original intention was that grid_spatial -> projection is always a projected coordinate system. It would be grid_spatial -> <something else> for non projected bounds.

That said, it's still a problem that needs fixing, whether by documenting and enabling the format you've described, or some more comprehensive overhaul of the entire grid_spatial subtree.

[Kirill888]

At the very least we should detect absence of expected keys and generate descriptive exception.

But we should probably just abandon the whole 4 corner system, and supply envelope or valid polygon.

[Kirill888]

Related issue and an annoying discrepancy is #556 when working with EPSG:4326.

Have to use lat|lon names in your product spec, but y,x in your dataset yaml :nauseated_face:

[Kirill888]

make it latitude|longitude not lat|lon

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[omad]

According to @SpacemanPaul , this information is created internally within Core code, is isn't written within dataset documents.

While there is some potential for confusion, with everything being named with x, y, it would make the internal code more complex for no particular gain.