Process ID: load_collection, load_stac and filter_bbox
Describe the issue:
These processes have an argument spatial_extent, which most commonly is used as a bounding box object with fields "west", "east", ...
When using EPSG:4326 (the default) to define an extent across the antimeridian, there are different approaches.
For example, to span from 1 degree west and 1 degree east of the antimeridian:
"west": 179, "east": -179: this is the most strict approach, following the GeoJSON spec. The coordinates are cleanly in the valid range [-180,180]. However, it seem that some people and implementations get confused as it breaks the (wrong) assumption that the west coordinate should be smaller than east coordinate."west": 179, "east": 181 and "west": -181, "east": -179: this is probably the most human/natural/intuitive way to handle this, but it breaks out of the valid [-180, 180] range"west": -179, "east": 179 which is exactly the opposite of the intent, so clearly wrong. However it often occurs in the wild when naively calculating the bounding box with west=min(x coords); east=max(x coords).
I think it's worth to clarify which approaches are acceptable and/or recommended in openEO, so that clients and backends can align properly.
For example:
Proposed solution:
I think approach 1 should be recommended, while approach 2 should still be accepted by backends.
Further context
As far as my CRS knowledge reaches, this is mainly a consideration for EPSG:4326, but I can imagine there are some other CRSes where this applies too.
Process ID: load_collection, load_stac and filter_bbox
Describe the issue:
These processes have an argument
spatial_extent, which most commonly is used as a bounding box object with fields "west", "east", ...When using EPSG:4326 (the default) to define an extent across the antimeridian, there are different approaches.
For example, to span from 1 degree west and 1 degree east of the antimeridian:
"west": 179, "east": -179: this is the most strict approach, following the GeoJSON spec. The coordinates are cleanly in the valid range [-180,180]. However, it seem that some people and implementations get confused as it breaks the (wrong) assumption that the west coordinate should be smaller than east coordinate."west": 179, "east": 181and"west": -181, "east": -179: this is probably the most human/natural/intuitive way to handle this, but it breaks out of the valid [-180, 180] range"west": -179, "east": 179which is exactly the opposite of the intent, so clearly wrong. However it often occurs in the wild when naively calculating the bounding box withwest=min(x coords); east=max(x coords).I think it's worth to clarify which approaches are acceptable and/or recommended in openEO, so that clients and backends can align properly.
For example:
Proposed solution:
I think approach 1 should be recommended, while approach 2 should still be accepted by backends.
Further context
As far as my CRS knowledge reaches, this is mainly a consideration for EPSG:4326, but I can imagine there are some other CRSes where this applies too.