Antimeridian and the Datacube storage model

[alexgleith]

I've just indexed a single STAC Item (this one https://deppcpublicstorage.blob.core.windows.net/output/dep_s2_geomad/0-0-4/066/021/2023/dep_s2_geomad_066_021_2023.stac-item.json) and it crosses the antimeridian, with lat/lon geometry split at the +/- 180 line.

I indexed it with one of the stac-to-dc tools.

In database, I see the longitude coordinates are:

    "lon": {
      "end": 180.830180550982,
      "begin": 179.96779787822723
    }

Which is correct, but sort of not ideal, as it goes past 180.

What is the right way to be storing this extent in the Datacube database?

[SpacemanPaul]

The ODC index assumes that every dataset extent can be projected to a 4386 lat/long bounding box - and then uses that for spatial search. There is no "right way" to index datasets like this into the postgres ODC index, they violates the implicit assumptions of the search implementation.

The new postgis index driver in 1.9.0 should handle this case more gracefully, but stac-to-dc probably won't work with it yet. Feel free to try and tell us where it breaks.

[alexgleith]

Ok, looking in OWS, it seems it gets the BBOX wrong. See:

{
  "EPSG:3577": {
    "top": -1700545.8609819806,
    "left": -2053594.3840014997,
    "right": 2323510.383276353,
    "bottom": -1988645.0311689891
  },
  "EPSG:3832": {
    "top": -1791999.9999998931,
    "left": -20037508.342789244,
    "right": 20002999.300643325,
    "bottom": -1887999.9999998985
  },
  "EPSG:3857": {
    "top": -1803765.142614628,
    "left": -19945093.066587448,
    "right": 20033923.61899101,
    "bottom": -1900360.4983862338
  },
  "EPSG:4326": {
    "top": -15.9917305948387,
    "left": -179.169819449018,
    "right": 179.967797878227,
    "bottom": -16.8241144459889
  }
}

[alexgleith]

That 4326 (lat/lon) bbox is around the wrong way... it should be from 179 to -179.

[alexgleith]

Ah, and they're set from the lon_min and lon_max

Which are around the wrong way.

[alexgleith]

The geometry in the space_view is incorrect.

[alexgleith]

Ok, and I can nail it down to these lines: https://github.com/opendatacube/datacube-ows/blob/8548e6841bda403aa350969803739e2d70306871/datacube_ows/sql/extent_views/create/011_create_new_space_view_raw.sql#L19-L27

[SpacemanPaul]

Yeah, that's where the action is. Also L89-L97 for extended eo3 metadata types (although they could easily be bundled together).

[alexgleith]

Ok, to close this off, I don't think there's an actual solution to this issue, so I'll try to write it up a bit here.

Here's the situation:

• Starting with a STAC Item, which has an appropriately split-at-the-antimeridian geometry
• Indexing into the Datacube results in a simplified bounding box with lon min/max of something like 179.9, 180.8, which is perhaps not right (the max should be -179.2) but works perfectly for the simple datacube extent queries
• The datacube also stores the valid_data or geometry polygon, which is projected, so it's a simple square
• Datacube OWS' update ranges function brings this geometry in, but does an ST_Transform to lat/lon, which results in a geometry that is incorrect, i.e., it spans the world from -179 to 179, rather than spanning it the correct way, from 179 to -179. This is caused by PostGIS, not any Python code
• In very simple terms, there's not way to do this correctly without putting lots of crazy logic in the SQL.

I really think that the best way to handle geometry as lat/lon is to store the footprints as geography data type. I guess the alternative is to store geometry in the native CRS, but then I don't know how the test for intersects will work when feeding it lat/lon coordinates again.

[SpacemanPaul]

I doubt the geography type would actually help us - it's a solution to a different problem (measuring the distance between points). We don't care about distances, we only care about boundaries and intersections, so geometry should work fine.

[alexgleith]

And for future references, here's how Datacube OWS renders data at the antimeridian.

[SpacemanPaul]

Honestly, that's a lot better than I would have predicted.