STAC: antimeridian bbox not split, causing wrong/missing results for global collections

[JeroenVerstraelen]

Summary

When loading data from a STAC collection for a spatial extent that crosses the antimeridian, the STAC backend sends a single large bbox request instead of splitting it into two separate requests. This results in vastly incorrect item counts and causes holes or strong differences in output compared to the OpenSearch implementation.

Reproduction

Observed via the LCFM_LSF_ANNUAL_S1_01WCT benchmark (global S1 mosaics collection), tile 01WCT which was specifically chosen because it crosses the antimeridian.

• Jenkins build: https://jenkins.vgt.vito.be/job/openEO/job/openeo-apex-benchmarks/454/
• openEO job: j-260226043841469db911f1f4ed3495d8 (CDSE staging, finished 2026-02-26, duration 11m06s)

Behavior

STAC implementation sends a single bbox crossing the antimeridian and gets 4913 STAC items (incorrect):

"bbox": [-179.3969135181096, 69.24723897024575, 177.93749065586138, 70.29008782695199]

OpenSearch implementation splits into two requests and gets 48 results (correct):

{ "west": 177.93749065586144, "south": 69.24723897024575, "east": 180.6030864818904, "north": 70.290087826952 }
{ "west": -182.06250934413856, "south": 69.24723897024575, "east": -179.3969135181096, "north": 70.290087826952 }

Impact

All global productions and projects using STAC collections will be affected when spatial extents cross the antimeridian.

Proposed Fix

Reuse the antimeridian-splitting logic already implemented for OpenSearch: detect when a bbox crosses the antimeridian and issue two separate STAC requests, then merge the results.

The STAC API community also recommends the antimeridian Python package for correcting GeoJSON geometries that cross the 180th meridian.

A unit test covering the antimeridian case should be added as well.

Priority

Not a release blocker for the current deploy, but should be treated as high priority to fix immediately after, as it affects all global productions.

[JeroenVerstraelen]

Deadline moved to 12/03 due to VLCC and EUGW issues.

[JeroenVerstraelen]

Note that the OpenSearch implementation also did some extra things on top of splitting the requests cc @EmileSonneveld:
https://github.com/Open-EO/openeo-opensearch-client/blob/bfb9abcb3d0a9ec2156202ff014dc59bf2a1889e/src/main/scala/org/openeo/opensearch/backends/CreodiasClient.scala#L87

[soxofaan]

CDSE STAC API seems to handle cross-antimeridian queries just fine, no need to split things up at the level of the STAC API query itself:

import pystac_client
url = "https://stac.opensearch.dataspace.copernicus.eu/v1/"
client = pystac_client.Client.open(url=url)
resp = client.search(
    method="GET",
    collections="sentinel-2-l2a",
    bbox=(179, 67, -179, 68),
    datetime=("2025-09-02", "2025-09-04"),
)
for item in resp.items():
    ...

returns only items in this cross-antimeridian window:
geojson.io visualisation

[soxofaan]

problem is probably that we don't provide the right bbox argument there:

"whole world" bbox (because of bad reprojection handling)

bbox=(-179, 67, 179, 68),

instead of cross-meridian bbox

bbox=(179, 67, -179, 68),

[soxofaan]

🤦 omg back to the drawing board

When I was testing STAC API responses, I was using CDSE STAC endpoint https://stac.opensearch.dataspace.copernicus.eu/v1 because the regular one was down/overloaded, and there anti-meridian handling worked fine if you provide the west and east borders of the bbox properly:

import pystac_client
url = "https://stac.opensearch.dataspace.copernicus.eu/v1/"
client = pystac_client.Client.open(url=url)
resp = client.search(
    method="GET",
    collections="sentinel-2-l2a",
    bbox=(179.5, 67.1, -179.5, 67.2),
    datetime=("2025-09-02T00:00:00", "2025-09-02T23:59:59"),
)
items = []
for item in resp.items():
    items.append(item)
print(len(items))

returns 2 items (S2C_MSIL2A_20250902T234641_N0511_R073_T60WWV_20250903T023412 and S2C_MSIL2A_20250902T234641_N0511_R073_T01WCQ_20250903T023412) in a couple of hundred milliseconds.

However, now that we're switched back to the original STAC API at https://stac.dataspace.copernicus.eu/v1/, it seems that anti-meridian handling does not work there.
The same snippet but with url = "https://stac.dataspace.copernicus.eu/v1/" then gives 160 items (in 7s)

[soxofaan]

Created cloudferro ticket CDSE-2834 because their pgSTAC implementation does not seem to handle anti-meridian searches correctly.

related:

• item search: clarify antimeridian handling of bbox radiantearth/stac-api-spec#473

[soxofaan]

From CDSE-2834: fix for lack of antimeridian handling in STAC API will come when they switch to SFEOS (end march, early april). So in meantime we have to workaround this unfortunately