Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bounding Box Terminology for Geographic CRS #31

Closed
rcoup opened this issue Jan 19, 2018 · 1 comment · Fixed by #34
Closed

Bounding Box Terminology for Geographic CRS #31

rcoup opened this issue Jan 19, 2018 · 1 comment · Fixed by #34

Comments

@rcoup
Copy link

rcoup commented Jan 19, 2018

7.8.4.18 currently refers to:

The bounding box is provided as four numbers:

  1. Lower corner, coordinate axis 1 (minimum longitude)
  2. Lower corner, coordinate axis 2 (minimum latitude)
  3. Upper corner, coordinate axis 1 (maximum longitude)
  4. Upper corner, coordinate axis 2 (maximum latitude)

And the OpenAPI yml also has

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.)

@cportele
Copy link
Member

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.

@cportele cportele self-assigned this Jan 26, 2018
cportele added a commit that referenced this issue Jan 29, 2018
resolves #31

Note that OpenAPI includes and links still go to the master branch,
i.e. will only be updated once the changes have been merged.
@cportele cportele added this to the Part 1, First Draft milestone Jan 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants