bbox crossing the antimeridian

[cportele]

Currently the specification says:

The bbox, if specified, must be encoded with an array containing the minimum and maximum values of each dimension: [<xmin>, <ymin>, <xmax>, <ymax>]. This follows the GeoJSON specification (RFC 7946, section 5).

"Minimum" and "maximum" are not correct for cases where the bbox crosses the dateline, at least if GeoJSON is used as the basis. See GeoJSON 5.2, the following is a rough bbox for the Fiji archipelago, spanning 5 degrees of longitude: [177.0, -20.0, -178.0, -16.0].

If GeoJSON is followed, the wording should be updated/clarified. If it should be strictly minimum/maximum, then the GeoJSON reference should be removed.

Happy to create a PR for review, but it would help to understand the intention for GeoParquet. I personally would prefer the first option and be consistent with GeoJSON, which is also what is used in OGC API Features and I think STAC.

[apps4uco]

Hi, What about using North South East West (relative to the center of the bounding box) I believe that would always work

[kylebarron]

There can be a discussion on what the correct wording should be. In effect the intended meaning of the existing spec is to follow GeoJSON, where the bbox is always [west, south, east, north]. And when crossing the antimeridian the numeric value of west is allowed to be larger than the numeric value of east

[jatorre]

Should we added as a comment in a specific question or should we added to some sort of FAQ?

[cholmes]

Call 11/7:

We should update our wording here - we use minimum and maximum, while geojson does east/west.

Issue for geoparquet is that there's non-geographic CRS's.

Consensus is to clarify that for geographic CRS's we follow GeoJSON, and update the spec. And to say 'less' on the non-geographic crs's, perhaps just something about being up to the client / crs.

@tschaub to take a pass and write a PR, we can continue review / discussion there.