search

opengeospatial / 2D-Tile-Matrix-Set

OGC 2D Tile Matrix Set & TileSet Metadata standard
https://www.ogc.org/standards/tms
Apache License 2.0
8 stars 10 forks source link

minus and plus infinity #26

Closed chris-little closed 3 years ago

chris-little commented 3 years ago

In 5.2.3, it states bounding box limits for that angular axis shall be set to minus and plus infinity.

How will that be implemented? I am not sure that NaN (Not a Number) which is defined in IEEE754, along with its behaviour with other numbers, for the standard representation of integer and floating point numbers in digital computers, is sufficient, as many programming languages do not allow such a value. Only some systems handle them correctly without generating a fatal error.

Or have I missed something? (I'm still a Fortran programmer at heart)

jerstlouis commented 3 years ago

@chris-little IEEE754 specifically defines +/- infinity as separate values than NaN, doesn't it?

I am however wondering about the need to refer to infinity rather than simply the -180..180 degrees of longitude and -90..90 degrees of latitude, which I believe is actually what is done? The bounding box is specified in projected coordinates anyway, as what is being tiled is the finite projected CRS plane, with any spherical coordinates already wrapped around (taking into consideration the projection center) before projection, and where explicit values are used in all current examples of polar (e.g. https://github.com/opengeospatial/2D-Tile-Matrix-Set/blob/master/schemas/tms/2.0/json/examples/tilematrixset/UPSArcticWGS84Quad.json#L7) and cylindrical projection (e.g. https://github.com/opengeospatial/2D-Tile-Matrix-Set/blob/master/schemas/tms/2.0/json/examples/tilematrixset/WorldMercatorWGS84Quad.json#L7).

This also applies to TMS based on geographic/plate carre projections, where -90..90 and -180..180 values are specified (e.g. https://github.com/opengeospatial/2D-Tile-Matrix-Set/blob/master/schemas/tms/2.0/json/examples/tilematrixset/WorldCRS84Quad.json#L8), as again the wrapping is already done before tiling the plane (otherwise we would have an infinite number of rows and columns, wouldn't we?).

@joanma747 Should this text be removed?

chris-little commented 3 years ago

@jerstlouis Thank you for bringing me up to date. I did not know that the later versions had introduced infinity separately from NaN.

Surely the real issue is how would they be implemented in practice and in specific languages?

jerstlouis commented 3 years ago

@chris-little The later part of my comment was saying that there should never be a need to refer to + or - infinity. And that is probably a good thing, because what I think is more relevant than how to implement in practice in a specific language (implementers could always come up with a way to represent it), is how to describe this in the TileMatrixSet JSON encoding: JSON does not define infinity (or NaN)!

So I think that current clause is more theoretical than anything, and I think that we may be able to remove it. Let's see what @joanma747 thinks :)

joanma747 commented 3 years ago

This is the text commented comes for OWS common. This is what I propose to solve this issue.

"Theoretically, there are cases where defining a bounding box could be problematic or impossible, such us angular axis of an Ellipsoidal, Spherical, Polar, or Cylindrical coordinate system. However, tiles need to be circumscribed to real coordinates and will deliberately avoid to enter into regions of the space where coordinates go to infinite or cannot be defined. For example, the WorldMercatorWGS84Quad tile matrix set (based on a cylindrical projection) deliberately avoids to get close to the poles. Since tiles are conterminous, it is always possible to define a bounding box that includes them all."