[Feature] `intersectsWith` does not correctly preserve antimeridian-crossing `MultiPolygon` geometries

[johntruckenbrodt]

Is your feature request related to a problem? Please describe.

intersectsWith does not correctly preserve MULTIPOLYGON geometries representing AOIs that cross the antimeridian.

Many GIS libraries and workflows (e.g. GDAL, GeoPandas, Shapely-based workflows, RFC 7946 GeoJSON) represent antimeridian-crossing polygons by splitting them into a MULTIPOLYGON. This is therefore a common and natural representation for users working with global datasets.

For example, the following WKT represents a small rectangle crossing the antimeridian:

MULTIPOLYGON (
(
(177.5 50, 
180 50, 
180 53, 
177.5 53, 
177.5 50)
), 
(
(-180 50, 
-174.5 50, 
-174.5 53, 
-180 53, 
-180 50)
)
)

When passed via

results = asf_search.search(
    platform="SENTINEL-1",
    intersectsWith=wkt,
)

the geometry is not preserved.

From tracing the code, this appears to happen because validate_wkt() converts disconnected MultiPolygons into their convex hull before the geometry is translated into CMR query parameters. For the example above, this effectively turns a narrow AOI around ±180° into an almost-global polygon.

Describe the solution you'd like

It would be great if intersectsWith preserved disconnected MultiPolygon geometries instead of replacing them with their convex hull.

Since NASA CMR already supports multiple polygon query parameters, one possible implementation would be to translate each polygon component into its own polygon[] parameter together with

options[polygon][or]=true

This would correctly preserve

• antimeridian-crossing AOIs,
• arbitrary disconnected AOIs, and
• the user's intended search footprint.

Describe alternatives you've considered

The current workaround is to bypass intersectsWith entirely and use raw cmr_keywords, for example

cmr_keywords=[
    ('polygon[]', '177.5,50.0,180.0,50.0,180.0,53.0,177.5,53.0,177.5,50.0'), 
    ('polygon[]', '-180.0,50.0,-174.5,50.0,-174.5,53.0,-180.0,53.0,-180.0,50.0'), 
    ('options[polygon][or]', 'true')
]

This produces the expected result, but it requires users to know CMR-specific query parameters and bypasses the higher-level intersectsWith interface.

Additional context

This appears to be a limitation of asf_search rather than CMR itself.

Unless I have overlooked something, translate.py currently only supports Point, LineString, and Polygon, so multipart geometries cannot currently be translated into multiple CMR polygon parameters.

Also, to obtain the same results in the ASF Data Search web interface, this geometry has to be provided:
POLYGON((177.5 50,185.5 50,185.5 53,177.5 53,177.5 50)).

Passing this polygon to intersectsWith triggers coordinate wrapping:

WARNING:asf_search:WKT REPAIR/VALIDATION: The following repairs were performed on the provided AOI:
["'type': 'WRAP': 'report': 'Wrapped 2 value(s) to +/-180 longitude'"]

However, this only wraps the coordinate values into the [-180, 180] range; it does not split the polygon at the antimeridian.

For example, the input coordinates at 185.5° are converted to -174.5°, effectively turning the geometry into approximately:

POLYGON((177.5 50,-174.5 50,-174.5 53,177.5 53,177.5 50))

which spans most of the globe instead of the intended narrow region crossing the antimeridian.

validate_wkt() does compute an unwrapped alternative internally for geometries whose wrapped longitude span exceeds 180°, but search_generator.wrap_wkt() currently discards this value and forwards only the wrapped geometry.

I'd be happy to help test a solution if this is something that would be considered.

[johntruckenbrodt]

partly addresses #163