You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bbox:
description: minimum longitude, minimum latitude, maximum longitude, maximum latitude
For geographic/polar/cylindrical/etc coordinate systems it's important to use (left, bottom, right, top); or (west, south, east, north) when referring to bounding boxes, since it's clearly possible to have useful bounding boxes that span the discontinuity.
eg. describing the area of the New Zealand Exclusive Economic Zone; longitudes 160.6°E - 170°W (spanning the antimeridian) & latitudes 55.95°S - 25.89°S
This should be represented as {160.6, -55.95, -170, -25.89}
But using "minimum" and "maximum" terminology leads to lots of software either:
asserting that x0 < x1 and failing because -170 < 160.6
attempting to correct "bad" boxes by normalising them (ie. to {-170, -55.95, 160.6, -25.89}) so it now describes the the rest of the world except the area we want
Alternatively, the spec could support longitudes <-180° and >+180° (currently not permitted), but that moves the problem to the server, since in order to filter the dataset properly the server needs to re-normalise or otherwise adapt them. Or leave it otherwise undefined like most of the other OGC specs.
OGC 06-121r3 D.13 Minimum bounding boxes discusses this and sits firmly on the fence ("[the min/max approach] can always be used by proper selection of the CRS"), but describes the above WSEN approach as:
b) For a circular coordinate, specify that the LowerCorner shall define the box edge furthest toward decreasing values, and the UpperCorner shall define the box edge furthest toward larger values. For longitude, the LowerCorner longitude would define the West-most box edge, and the UpperCorner longitude would define the East-most box edge. (The LowerCorner would no longer always use the minimum value, and the UpperCorner would no longer always use the maximum value. The value at the LowerCorner can be greater than at the UpperCorner when this bounding box crosses the value discontinuity.)
The text was updated successfully, but these errors were encountered:
Thanks, that makes sense. I will write a pull request to change it to "west, south, east, north" and include a note about extents crossing the antimeridian.
7.8.4.18 currently refers to:
And the OpenAPI yml also has
For geographic/polar/cylindrical/etc coordinate systems it's important to use (left, bottom, right, top); or (west, south, east, north) when referring to bounding boxes, since it's clearly possible to have useful bounding boxes that span the discontinuity.
eg. describing the area of the New Zealand Exclusive Economic Zone; longitudes 160.6°E - 170°W (spanning the antimeridian) & latitudes 55.95°S - 25.89°S
This should be represented as
{160.6, -55.95, -170, -25.89}
But using "minimum" and "maximum" terminology leads to lots of software either:
{-170, -55.95, 160.6, -25.89}
) so it now describes the the rest of the world except the area we wantAlternatively, the spec could support longitudes <-180° and >+180° (currently not permitted), but that moves the problem to the server, since in order to filter the dataset properly the server needs to re-normalise or otherwise adapt them. Or leave it otherwise undefined like most of the other OGC specs.
OGC 06-121r3 D.13 Minimum bounding boxes discusses this and sits firmly on the fence ("[the min/max approach] can always be used by proper selection of the CRS"), but describes the above WSEN approach as:
The text was updated successfully, but these errors were encountered: