Closed Kirill888 closed 1 year ago
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.
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.
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:
make it latitude|longitude
not lat|lon
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.
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.
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.
Expected behaviour
Should be able to define Dataset
grid_spatial
with Geographic CRS, likeEPSG:4326
usinglatitude/longitude
keys instead ofy,x
for forgeo_ref_points
construct:Actual behaviour
Fails with
KeyError
in here:https://github.com/opendatacube/datacube-core/blob/a82de5c031d711043b5dedbb09b609de0d544a4f/datacube/model/__init__.py#L273-L274