search

opengeospatial / geoparquet

Specification for storing geospatial vector data (point, line, polygon) in Parquet
https://geoparquet.org
Apache License 2.0
795 stars 56 forks source link

bbox crossing the antimeridian #112

Closed cportele closed 1 year ago

cportele commented 2 years ago

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 commented 2 years ago

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

kylebarron commented 2 years ago

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 commented 1 year ago

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

cholmes commented 1 year ago

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.