Inaccurate computation of Lon/Lat bounds in `geobox_info`

[Kirill888]

Expected behaviour

• For every point X
  • IF X.lonlat not in ds.extent_lon_lat, THEN X.xy_native not in ds.extent_native

Actual behaviour

• For some datasets ds.extent_lon_lat is computed incorrectly and is smaller then the actual lon/lat bounds, so some points within the dataset footprint will be classified as outside when using lonlat

Offending code is here:

https://github.com/opendatacube/datacube-core/blob/d561b4a1c8a8dce4c98fd524eca5899e98303241/datacube/model/utils.py#L47-L62

This just transforms 4 points of a bounding rectangle to EPSG:4362

to_lonlat( bounds(valid_data | image_bounds))

this computation sometimes results in smaller bounds than actual, a more proper way to first "increase resolution" of the native polygon, possibly add some buffer, then translate that to EPSG:4326 and then compute envelope of the result. Converting geometry to a different CRS with increased resolution is already supported by datacube.utils.geometry.Geometry class, but we should probably use "higher resolution" than what is currently default (100km)

envelope(polygon(valid_data|image_bounds).to_crs(epsg4326, resolution=1000))

[Kirill888]

Same problem here:

https://github.com/opendatacube/datacube-core/blob/8b865d2b4aa7a8f6f65c62e6c10a3ca65c8da387/utils/ls_usgs_prepare.py#L94

[Kirill888]

And pretty much all other prepare scripts too.

[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.

[Kirill888]

pretty sure this bug is still a bug

[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.

[Ariana-B]

native_geobox is only used in ingestion, which will be deprecated in 1.9 and removed in 2.0.