Vote for your favorite bbox encoding for Tile Matrix Set - Tile Set Metadata

[joanma747]

This are the posibilities

0.-
"bbox": [-180, -90, 180, 90]

1.-
"bbox":
{
    "lowerBounds": [ -180, -90 ],
    "upperBounds": [ 180, 90 ]
}

2.-
"bbox":
{
   "Lat" : [ 7.01, 7.22 ],
   "Lon" : [ 50.63, 50.78 ]
},

3.-
"bbox":
{
    "lowerBounds" : { "Lon" : -180, "Lat" : -90 },
    "upperBounds": { "Lon" : 180, "Lat" : 90 }
}

4.-
"bbox": [{ 
    "axisLabel": "Lat",
    "lowerBound": -80,
    "upperBound": -70,
    "uomLabel": "deg",
},{
    "axisLabel": "Long",
    "lowerBound": 0,
    "upperBound": 10,
    "uomLabel": "deg",
}]

Please sort them by preference being the first one the most preferred. Ex. 4,3,2,1,0 means that you love 4 and hate 0.

[jerstlouis]

2,3,1,0,4

[cportele]

0,1,2,3,4

Also note that "lower/upper bounds" is problematic for bboxes crossing the antimeridian.

[joanma747]

This issue is related to: https://github.com/opengeospatial/ogcapi-common/issues/91

[chris-little]

0,1,2,3,4 Simpler is preferable, providing it is lon. then lat.

[joanma747]

Just to clarify the motion, this is for CRS bbox (a bbox expressed in a known CRS) and not for lon/lat/WGS84 bbox only.

[cportele]

... where "known CRS" is a projected CRS (if a geographic CRS like CRS84 is used, there will be an implicit plate carree projection, like in WorldCRS84Quad) and always a 2D CRS.

[jerstlouis]

@cportele does that statement apply to the encodings explicitly identifying the geographic CRS axes though?

[cnreediii]

Hmm. “Everything should be made as simple as possible, but no simpler” (Simplified version of 1933 lecture by Einstein). A few things to consider are:

1. Is the bbox encoding consistent with the OGC Project Document 08-038r7 TITLE: Revision to Axis Order Policy?
2. Is the bbox encoding consistent with rules and requirements in OGC Topic 2: Referencing by coordinates?
3. Is the bbox encoding consistent with other OGC standards?

I worry that if the encoding is too simple (option 0), there is a strong possibility that a client will have no idea what the heck the content means or how it should be interpreted. As Clemens points out if there is a known CRS expressed elsewhere then some of the ambiguity is removed. That said, there is a reason that WKT for CRS provides for explicitly stating elements such as axis order - more along the lines of option 4 above.

Anyway, apologies for jumping into the middle of this discussion as I probably missed much of the background discussion - but if I put on my OAB hat, these questions pop into my mind.

And Chris, your comment regarding a bounding polygon is relevant. Need to think about that - as well as where and how bounding spheres fit into the discussion.

[cportele]

@jerstlouis - Well, WorldCRS84Quad is defined as "tiles in the Equirectangular Plate Carrée projection in the CRS84 CRS for the whole world." But maybe that is an incorrect statement and needs to be fixed, too, since you are right, what is really used in the TMS are lon/lat and what is used is the "pseudo-Plate-Carree projection" that we know from WMS.

[cportele]

@cnreediii - Since the CRS is known (it is explicitly stated as another property in the same object), option 0 is a "yes" for all your questions. And I do not see how it is more ambiguous than the other options, it has the same information, it is just more compact.

To do something with the information the CRS must be known anyhow, either the software knows the CRS already (by identifier) or it will have to parse the CRS definition (to determine information about the CRS including, but not limited to the axis names and order).

[chris-little]

@cnreediii @cportele The best link to envelope definitions is https://en.wikipedia.org/wiki/Envelope_(disambiguation) . As you see, most are non-rectangular. For multiple dimensions, the other terminology that has been used is 'convex hull', which is tighter than a bounding box or bounding sphere, and has nicer mathematical properties than an envelope.

[mcechini]

I should be able to use this to represent a bounding box in EPSG:3413 or EPSG:3031, yes? And if so, using lat/lon is problematic. What I want to use are the coordinates appropriate for that projection.

I think option 0) runs the risk of being too generic. Having gotten lost MANY a time between coordinate ordering of WMS 1.1.1 vs 1.3.0 or gdal_translate vs gdalwarp... a flat structure like that is frustrating at times.

The same goes for options 2) and 3) that use lat/lon terminology or unspecified ordering.

Option 4) is the overachiever and a bit too verbose.

I personally like something along these lines. It can then be contextualized within the coordinate system/projection.

"bbox":
{
    "minx": -180,
        "miny": -90,
        "maxx": 180,
        "maxy": 90
}

[jerstlouis]

@mcechini To clarify Option 2,3 and 4, the abbreviated axis name of the relevant CRS are to be used, rather than a fixed "Lat" or "Lon" -- those were just examples for CRS where those are the axis abbreviations.

Part of the reasoning behind not using min and max that we discussed in the call was recognizing the fact that for crossing the dateline the first (e.g. longitude) value would be greater than the second.

[joanma747]

The last proposal

 "boundingBox" : {
      "crs" : "http://www.opengis.net/def/crs/EPSG/0/4326",
      "axesLabels" : ["Lat", "Lon"],
      "lowerCorner" : [
         -90,
         -180
      ],
      "upperCorner" : [
         90,
         180
      ]
   },
   "tileMatrices" : [
      {
         "topLeftCorner" : [
            90,
            -180
         ],
      }
   }

This seems to be compatible with 1.0 and satisfies making the axes order explicit and expressing bbox as two points. In telco 2021-02-25 seemed a good compromise.

[chris-little]

@joanma747 In a 3D world, I always have problems with terms like lowerCorner or topLeftCorner and similar. Left from where? Human looking at a screen, or as a camera? (E.g. looking at a theatre stage or from a stage at the audience.) Top with respect to what? A vertical screen? A horizontal table screen or phone or horizontal map displayed in VR or AR?

The mathematical (min, max) is unambiguous, providing one is rigorous and then
(min=45, max=-45) goes 270 across the anti-meridian, and (min=-45, max=+45) goes 90 across the meridian.

[mcechini]

lowerCorner and upperCorner seem to be ambiguous terms without left or right specified. Is that intentional? Especially since you do include Left in the TileMatrix definition. Sorry, I missed the discussion.

I still generally think that min[xy] and max[xy] values are the most straightforward. It also would allow for minz and maxz. I see @jerstlouis's comment previously regarding the issue with crossing the dateline. But maybe that's ok. If max < min, then that just means you have a bounding box that is offset. Using your proposed example, and @chris-little's first bbox, we would have the following.

 "boundingBox" : {
      "crs" : "http://www.opengis.net/def/crs/EPSG/0/4326",
      "axesLabels" : ["Lat", "Lon"],
      "lowerCorner" : [
         -90,
         45
      ],
      "upperCorner" : [
         90,
         -45
      ]
   },
   "tileMatrices" : [
      {
         "topLeftCorner" : [
            90,
            45
         ],
      }
   }

I'm not sure that's all that clear. And, IMO, no matter how you slice it, having a bbox that crosses the anti-meridian always has a tiny bit of unavoidable confusion. But, for me, that is reduced with simpler min/max notation that I can do a quick check on.

[jerstlouis]

@mcechini Personally, I prefer the lowerLeft & upperRight names, precisely to allow for lowerLeft.lon > upperRight.lon indicating crossing the dateline. @joanma747 What was the reason for omitting left & right here in TMS 1.0? I really did like the fact that we were not completely breaking compatibility by keeping this :)

Re: minz and maxz as those corners are points, they could also be points with 3 coordinates.

[mcechini]

I can concede to lowerLeftCorner & upperRightCorner. :) lowerCorner & upperCorner not so much, but maybe that was an oversight in the example.

Good point on the 3 coordinates for min/max z

[jerstlouis]

@mcechini I know it was not an oversight in the example, because it is how it is currently specified in version 1.0 of the TileMatrixSet, but I don't recall why that was chosen other than vaguely remembering that I was not really in agreement for those same reasons :)

Allowing min > max to cross the dateline as suggested really strikes me as being at odd with terminology.

[cnreediii]

Off topic, but as Chris points out as e begin to think of a 3d tile matrix extension standards life gets more interesting :-) We suddenly have structures such as oriented bounding boxes. Sorry, but I do not use the term "geovolume" . . .

[jerstlouis]

@cnreediii I've been saying this for a while, but I dislike calling this standard strictly two-dimensional. Sure, the tiling sort of assumes it's tiling a 2D plane (though maybe that even isn't exactly true with the variable width tile matrices, which work on the assumption that the plane is a flattened sphere).

All TileMatrixSets referencing a geographic CRS at least are definitely 3D based on spherical coordinates, with height extending infinitely away into outer space, and all the way down to the center of the earth.

One could easily also define slices of the Earth and/or the atmosphere to stack multiple of these tiles with a min and max Z. And one could also easily extend these into an octree so that lower zoom levels are more generalized. And then it really gets into that Topic 21 DGGS - Part 4: Axis-aligned DGGS, but the 2DTMS can provide a solid foundation for building this.

We use these not-so-2D tile matrices extensively in our 3D software, and in fact I am writing code right now loading, thinning, processing and visualizing 3D point clouds entirely based on 2DTMS.

I believe what we were trying to avoid confusion with when qualifying this as 2D was 3D Tiles, which uses Bounding Volume Hierarchies instead of a fixed tiling scheme (which are not required to be mathemtical tiles at all, if we recall our discussions at the Ottawa TC).

But all this to say that when using 2DTMS for 3D as we do, the tiles themselves have a fixed position orientation based on their identifiers, and data located in these tiles can inherit that base orientation (and further orient themselves relative to that base orientation), much like in CDB and the GeoPackage extension for 3D models that we are proposing.

Long story short: we can really do 3D with the 2DTMS, and we don't need oriented bounding boxes to do so -- it can be done with either 2 or 3 numbers.

EDIT: This was expanded upon (with great diagrams and all!) in #27

[joanma747]

Correction:

 "boundingBox" : {
      "crs" : "http://www.opengis.net/def/crs/EPSG/0/4326",
      "axesLabels" : ["Lat", "Lon"],
      "lowerLeftCorner" : [
         -90,
         45
      ],
      "upperRightCorner" : [
         90,
         -45
      ]
   },
   "tileMatrices" : [
      {
         "topLeftCorner" : [
            90,
            45
         ],
      }
   }

WE will proceed to do the change

[joanma747]

We will add text suggestion that other dimensions can be added on top of the tiles.

Add a diagram showing that it a TMS can be used as columns and not only flat tiles and another diagram about time slices.

[cnreediii]

Sorry for this late question! Today when reading this discussion I wondered whether there was any consideration given to aligning terms/element names with WKT for CRS (http://docs.opengeospatial.org/is/18-010r7/18-010r7.html)? This may be a broader question related to all OGC API CRS content.

[chris-little]

I think @cnreediii 's suggestion excellent, and of course, alignment with the BBOX definitions/syntax used in OGC API-Features, Common Core and Collections (or whatever they are called today) would be worth striving for.

[joanma747]

No problem with aligning with WKT in general

BUT

could you be more precise on the "page" we have to read or the "variable" WKT uses and we could mimic?

[joanma747]

Considering that the present today saw that WKT uses lowerLeft and upperRight we have a "final" proposal to move:

    "boundingBox" : {
      "crs" : "http://www.opengis.net/def/crs/EPSG/0/4326",
      "axisLabels" : ["Lat", "Lon"],
      "lowerLeft" : [
         -90,
         45
      ],
      "upperRight" : [
         90,
         -45
      ]
   },
   "tileMatrices" : [
      {
         "pointOfOrigin" : [
            90,
            45
         ],
      }
   }

MOTION: The OGC API Tiles SWG proposes to change the JSON encoding for a bbox to the above syntax.

Moved: Jerome Second: Joan

Discussion: None NOTUC Attendees: Jerome ST-Louis, Joan Maso, Jeff Yutzler, Satish Sankaran, Jeff Harrison.

[cportele]

I guess then it should be "topLeft" not "topLeftCorner"? Or rather "upperLeft"?

[jerstlouis]

@cportele we briefly discussed that and @joanma747 had a feeling that this would be different because this is the one corner of the tile matrix.

Looking at https://raw.githubusercontent.com/opengeospatial/2D-Tile-Matrix-Set/master/standard/figures/TileMatrixSet2D.png I think that was renamed to pointOfOrigin anyways?

[joanma747]

A grammar mistake has been detected and it would be axisLabels ('e' -->'i').

[jerstlouis]

@joanma747 axes plural is axes, singular is axis. Isn't it the labels for more than one axis?

[joanma747]

Applied to documents, schemas and examples.

[joanma747]

"boundingBox":
{
       "envelope" :
       {
          "Lon" : [ 50.63, 50.78 ],
          "Lat" : [ 7.01, 7.22 ]
       },
       "orderedAxes" : ["Lon", "Lat"],
       "crs" : "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
},

[jerstlouis]

I had suggested that we merge the boundingBox directly into the TileMatrixSet, since conceptually the TMS could be said to inherit from a BoundingBox (this was pointed out as also being the case in GeoPackage).

However, I realized that with an nD extension (#27) from TMS, we plan on defining the extra dimensions separately, so this bounding box would still be only 2D.

So should there be a clarification that the CRS for the bounding box should always be exactly 2D, for the purpose of the basic 2D tiles, which might differ from the "supportedCRS" which might be 3D/4D/...?

That would also mean that both the pointOfOrigin and the boundingBox lowerLeft / upperRight would be specified using the boundingBox CRS rather than the supportedCRS, and would always have exactly 2 coordinates.

Otherwise we could consider merging the BoundingBox properties directly in the TileMatrixSet object, and avoid the redundant crs this way (it can remain as supportedCRS or be renamed to crs), but we would need to consider the case when this CRS is 3+D.

Currently, 2DBoundingBox.json has axisLabels with min/max 2 items.

There is also orderedAxes in the TileMatrixSet object currently. Do we need both? If all coordinates follow the boundingBox CRS (and we explicily name the extra dimensions for nD), then I think at least one of them is superfluous.

However I really think we should keep one of them (either axisLabels or orderedAxes), and use it in all examples, even though it is optional and redundant (and always following the CRS order).

The explicit listing of axis labels makes it obvious what ordering was used when putting the TMS together, such as if the wrong order was mistakenly used, as was found to be the case in our own examples (#31).

It is also very convenient to be able to tell the CRS axis order from glancing at the TMS definition, without having to dig into the CRS definition.