Adding a Stand-Alone Tile Matrix for 4326 (compatible CRSes?)

[ayoumans]

The TMS standard identifies defined tile matrix sets and it includes the World CRS 84 Quad TileMatrixSet in the Equirectangular Plate Carrée projection in the CRS84 CRS for the whole world. However, there is a footnote that says that some implementations prefer to define this TileMatrixSet using the CRS defined by 4326. This tile matrix set, which is based on 4326 is key to US DoD. It is a suggestion that this be made its own, stand-alone definition. The issue is that the name of this and how it is defined is not well-defined. Frequently it is just called 4326 tile matrix set, but it is not a projection. There should be some definition of this, which, in internal communications with coworkers indicate that this should better be called:

Equirectangular Plate Carr’ee (4326) | Operation Method EPSG 1029 | Derived | Equirectangular

I think developers will miss the reversed axis order and just needs to be spelled out. In other words...add a 9th TileMatrixSet to Annex D to standardize this TMS.

I am hoping that we can loop NGA into this discussion to get a better opinion and clarify the tile matrix sets in NSG Profiles on Tiles, GeoPackage and other standards.

[ghobona]

Cc: @cmheazel

[jerstlouis]

@ayoumans it would be good to clarify the use case. What exactly should be specified in lat, lon order?
The TMS rows and columns would not change. Defining the extents inside the TMS in lon, lat order just introduces more confusion, and same goes for specifying extents etc.

GeoJSON specifies CRS84. If the intent is to have lat, lon order in returned GeoJSON data (with a 4326 crs identifier), this would make sense, but I don't think creating a new TMS would be the best way to go about it -- a query parameter might better suited for that purpose.

[ayoumans]

Straight from: D.2 World CRS84 Quad TileMatrixSet definition (http://www.opengis.net/def/tilematrixset/OGC/1.0/WorldCRS84Quad)

This Tile Matrix Set defines tiles in the Equirectangular Plate Carrée projection in the CRS84 CRS for the whole world.

---

In Annex D, there is a note under the world CRS84 Quad TileMatrixSet definition (in D.2) that says that some implementations prefer to define this TileMatrixSet using the CRS defined by 4326. Even though the definition of the TileMatrixSet is the same, based on the importance, and lack of clarity in what this is actually called, this should be more clearly defined: Equirectangular Plate Carr’ee (4326) | Operation Method EPSG 1029 | Derived | Equirectangular?

For example, if you look at the NSG profile of the OGC WMTS standard (https://nsgreg.nga.mil/doc/view?i=4553), Annex C, C.3., you will see that EPSG::4326 is the common name, but this is not a projection, so the name of this should be spelled out a little better, which is a flaw in the profile. I like how you say in D.2 that, "...this defines tiles in the Equirectangular Plate Carree projection in 4326...". Also, you will note in the NSG profile that, "These tiles are fully compatible with the World CRS84 TileMatrixSet definition as specified in OGC 13-082r2 “WMTS Simple Profile”. Specifically, zoom levels 0-17 match the “WMTS Simple Profile” while zoom levels 18-23 provide additional flexibility for NSG users. " So, I would list the zoom levels too for 18-23. Yes, the axis order should be called out too.

I do not think that a stand-alone informative definition for "EPSG::4326" would be confusing. Developers are just going to search for "4326" and copy the definitions.

It is what the US DoD uses. Just my 2 cents.

[joanma747]

We need to clarify more (more than a food note) about the EPSG:4326. Axis order etc. Can we use WorldCRS84Quad with vector tiles in EPSG:4326?. How defines de CRS?. What if the format allow for defining the CRS internally (Shapefile, or even GeoTIFF?

Some text that can help in the clarification:
"EPSG:4326 is equivalent to WGS 84 2D, or the horizontal component of the WGS 84 3D system. The EPSG registry title for this code is Geographic 2D CRS." Very specific details on 4326 can be reported by going to https://epsg.org/home.html and typing in 4326 in the text search box and then generating a detailed report. To really avoid confusion, perhaps the reader should be directed to such a report - or at least a synopsis of that report. (Carl suggestion)

Is the CRS specified in the TileMatrixSet mandatory in the response of a OGC tiles API?. Possibilities:

1. Yes in any case
2. Yes but we are flexible with CRSs that could be equivalent: e.g CRS84==EPSG4326
3. Yes, but in vector tiles you can use a tiling schema (e.g LCC) but internally encode coordinates in e.g CRS84 (e.g. there are some feature tile formats that only provide support to one CRS).
4. No, in vector tiles you can use a tiling schema (e.g LCC) but internally encode coordinates in e.g Polar stereographic

What is gonna be?
Lets accept 2,3 and do a wording: "In general the client will expect the CRS to be the one declared in the TMS but this standard tolerates some flexibility for instance 2(expand) and 3 (expand) only for formats that specify the CRS and the axes order."

Actually the second part this is for OGC API tiles and not for TMS. There is a suggestion from @jerome to support better the case 3 with CRS= in addition to /{tileMatrixSetId}/

[joanma747]

I believe our last entry lost track of the discussion. The original request was to introduce WGS1984Quad in the NGA.STND.0063_1.1_WMTS%202018-04-27.pdf (page 65). I have divided the subsection in Annex D in 2 "Variant 1" CRS84, and "Variant 2" EPSG:4326 and provided the necessary explanation. Variant 1 is still the recommended one. The other considerations in the comment above belongs to the OGC API tiles and should be applied there.

[joanma747]

Changes have been applied in the document and in the schema. In particular we have added the "zooms" 18 to 23 as requested

[jerstlouis]

@joanma747

I believe our last entry lost track of the discussion.

Actually, the resolution was that because we accepted the flexibility of equivalent TileMatrixSets, the new http://www.opengis.net/def/tilematrixset/OGC/1.0/WGS1984Quad and http://www.opengis.net/def/tilematrixset/OGC/1.0/WorldCRS84Quad would be fully equivalent for (almost) all purposes, so we should not define them as separate URIs.

An implementation would be free to define it either way (variant 1 or 2), but I believe we are reducing interoperability if we define a separate URI, as clients will look for one in particular and not realize that they can also use tilesets using the other URI.

So I suggest we get rid of the WGS1984Quad URI (but we can keep both example variations on how it can be described).

A separate URI would not be useful with raster data (e.g. JPEG, PNG, GeoTIFF) where CRS84 and EPSG:4326 are equivalent, nor with GeoJSON or Mapbox Vector Tiles which require CRS84. It would only make sense to have a separate URI with a different default CRS for vector formats supporting multiple CRSes, such as the upcoming Features & Geometry JSON. Since this is not the common use case though, we may want to rely on the crs query parameter in Tiles instead, and avoid the need for that separate URI.

[ayoumans]

Wouldn't you need 2 URI's to link to the 2 different schemas??? WorldCRS84Quad links the user to the schema a http://schemas.opengis.net/tms/1.0/xml/examples/WorldCRS84Quad.xml. The schemas are what is different and should be well-defined and spelled out to eliminate confusion.

[jerstlouis]

@ayoumans the WorldCRS84Quad tiling scheme defines exactly the same tiling structure and the same scales/resolutions/zoom levels as this EPSG:4326 WGS1984Quad variation.

The EPSG:4326 and CRS84 CRSes are also fully equivalent for tiles in PNG, JPG, GeoTIFF, GeoJSON or Mapbox Vector Tiles formats.

So I am more concerned about the confusion of having some tilesets in those common formats marked as WGS1984Quad that clients only recognizing WorldCRS84Quad will not realize that they are perfectly suitable for them.

The use case for separate URIs of these equivalent TMS is practically non-existent (and I think better covered by a separate CRS parameter, e.g. to force GeoJSON vector tiles to be returned in lat, lon order), as we discussed in October last year.

[jerstlouis]

@ayoumans See this commit in my PR #32

I asked @joanma747 to review as well.

..but any standard that is built off of this, and uses EPSG for the TileMatrixSet will have to define their own schema as an annex...even though they are MOSTLY the same.

What I am saying is that the http://www.opengis.net/def/tilematrixset/OGC/1.0/WorldCRS84Quad TileMatrixSet is perfectly suitable for tilesets using CRS84, EPSG:4326, or any of the datum realizations which are part of the WGS84 datum ensemble (e.g. EPSG:9057).

I don't think new TileMatrixSets should be defined if they are completely equivalent to WorldCRS84Quad. However, if they have an offline TileMatrixSet definition or a self-hosted local description of this TileMatrixSet, they are free to describe it as done in Variation 2, i.e. using EPSG:4326 instead of CRS84 and the BoundingBox and PointOfOrigin flipped accordingly.

However, I suggest we add a crs field to the TileSet metadata, where a CRS can be specified, where the particular CRS in use could be specified, e.g. CRS84, EPSG:4326 or EPSG:9057 (G1762).

[jerstlouis]

One possible resolution would be to make supportedCRS an array.
This way we could say:

"supportedCRS" : [
   "http://www.opengis.net/def/crs/EPSG/0/4326",
   "http://www.opengis.net/def/crs/EPSG/0/4979",
   "http://www.opengis.net/def/crs/OGC/1.3/CRS84",
   "http://www.opengis.net/def/crs/OGC/1.3/CRS84h",
   "http://www.opengis.net/def/crs/EPSG/0/8888",
   "http://www.opengis.net/def/crs/EPSG/0/9053",
   "http://www.opengis.net/def/crs/EPSG/0/9054",
   "http://www.opengis.net/def/crs/EPSG/0/9055",
   "http://www.opengis.net/def/crs/EPSG/0/9055",
   "http://www.opengis.net/def/crs/EPSG/0/9056",
   "http://www.opengis.net/def/crs/EPSG/0/9057"
]

and we could define that the pointOfOrigin order follows the BBOX CRS.

These CRSes are all part of the EPSG:4326 datum ensemble geographic lat/lon can all be tiled perfectly fine with WorldCRS84Quad.

Then the actual CRS of the data should be defined in the TileSet.

[joanma747]

May be. Do not forget that people are free to define whatever TileMatrixSet they want, so you cannot prevent people defining variations. @ayoumans requested to clarify how a TMS in EPSG4326 will look like, and this is what I did. There is nothing wrong in doing that (adding a new TMS).

A TileMatrixSet not only defines a tile space, it also defines how to transform tilerow and tilecol into coordinates. Implicitly you set up a deal between the client and the server about that. If you add an array of CRSs in the TileMatrixSet, you no longer know how to do that (axis order and other small differences among CRSs. If all these EPSG numbers are identical, why they where defined in the first place?)

We are recommending CRS84 so people are "encouraged" to use it. We favor long/lat for a reason (CORRECTION: tilerow tilecol corresponds to the "first axis"). Having an array of CRSs prevents recommending anything, and now you do not know which one is the first coordinate. It is even more confusing.

The actual actual CRS cannot (only) be defined in the TileSet because you have bboxes and pointOfOrigin in the TileMatrixSet.

[jerstlouis]

There is nothing wrong in doing that (adding a new TMS).

Of course people can define new TMS and variations, but if there is already a registered TMS that correspond to the same thing, the recommendation is not to do that.

it also defines how to transform tilerow and tilecol into coordinates. Implicitly you set up a deal between the client and the server about that.

That is the assumption that I am challenging here, I don't think it should. I think the TileSet CRS should do that.
And I am challenging this assumption because of:

• GeoJSON vector tiles tiled according to any tile matrix set will always have CRS84 coordinates & axis order, because that is what the format requires
• the different datum realizations (e.g. EPSG:8888, EPSG:9053..9057) which are all part of the same datum ensemble (e.g. EPSG:4326)
• the 3D variants (e.g. EPSG:4979 adding h to EPSG:4326, CRS84h adding h to CRS84)
• the different axis order (e.g. EPSG:4326 and CRS84) which is meaningless for most common tile formats (GeoTIFF, JPEG, PNG, GeoJSON, Mapbox Vector Tiles)
• each dataset / tileset might have a different Epoch as well which will affect the coordinates -- but tile spaces do not move with tectonic plates

To me it makes much more sense to say that a Tile Matrix Set defines the tile space, not the content of that tile space. I believe this aligns with the conceptual model as well. We cannot talk about the axis order of the data because there is no data yet. The TileSet is what tiles up the data into tiles, so conceptually, I believe the CRS of the data belongs to the TileSet.

If you add an array of CRSs in the TileMatrixSet, you no longer know how to do that (axis order and other small differences among CRSs.

I am suggesting the TileSet CRS would define this

If all these EPSG numbers are identical, why they where defined in the first place?

Because of different realizations of the datums part of the same datum ensemble (e.g. EPSG:4326), 2D vs. 3D CRS, axis order... The distinction between the realizations and epochs matter for precision mapping. But regardless of whether precision is required, the exact same tiling scheme works with all of them because they are all defined in the same global plate carre projection. When displaying multiple tilesets of different realizations together, the data would line up except at high resolution, where the adjustment could be done based on the tileset CRS & epoch vs. the display CRS & epoch. But if the tilesets are treated as completely different, it will be much more difficult to bring that data together.

We favor long/lat for a reason (tilerow corresponds to the "first axis").

I was confused with that recommendation, because isn't it the other way around? The first axis in CRS84 is longitude, which corresponds to columns, not rows. (and the order in Tiles API is {tileMatrix}/{tileRow}/{tileColumn}).

Having an array of CRSs prevents recommending anything, and now you do not know which one is the first coordinate. It is even more confusing. The actual actual CRS cannot (only) be defined in the TileSet because you have bboxes and pointOfOrigin in the TileMatrixSet.

And the pointOfOrigin and the boundingBox are the only places where I think we should care about coordinate order in the TMS definition, and boundingBox already has its own single CRS. I am suggesting that the pointOfOrigin follows the bounding box CRS order, because the pointOfOrigin actually is the point in the boundingBox, not in the CRS. e.g. if you have a CRS84h 3D CRS, you should still provide only 2 coordinates pointOfOrigin, not 3.

[joanma747]

We favor long/lat for a reason (tilerow corresponds to the "first axis").

I was confused with that recommendation, because isn't it the other way around? The first axis in CRS84 is longitude, which corresponds to columns, not rows. (and the order in Tiles API is {tileMatrix}/{tileRow}/{tileColumn}).

My typing mistake. I wanted to say "We favor long/lat (CRS84) for a reason (tilecol corresponds to the "first axis"). Sorry. Edited in the original post.

To me it makes much more sense to say that a Tile Matrix Set defines the tile space, not the content of that tile space. I believe this aligns with the conceptual model as well. We cannot talk about the axis order of the data because there is no data yet. The TileSet is what tiles up the data into tiles, so conceptually, I believe the CRS of the data belongs to the TileSet.

I cannot agree with that.
All starts by defining a CRS; normally a projected CRS. Only when you define a CRS you have a well defined Euclidean space with axis and an origin of coordinates. They you define pixels/cells on it by creating a grid (as in CIS) and only after you have that, you group your pixels/cells into tiles and you create a TileMatrixSet. An only after you have completed all this in you imagination you can add the data. Saying that the data define your CRS is wrong. The CRS exists in the first place and you reference your data to the CRS by adding coordinates to the data.

You cannot define a TileMatrixSet without a CRS. If you try to define the TileMatrixSet without a CRS, you change completely the rules of the game. I could try to play that game, but it is another game. The definition of TileMatrixSet changes completely and becomes just a mechanism to divide an space that has not been defined yet. The divisions are "floating" with no origin or position. It is possible to imagine, but this is not my old TMS. It is a new thing.

When displaying multiple tilesets of different realizations together, the data would line up except at high resolution, where the adjustment could be done based on the tileset CRS & epoch vs. the display CRS & epoch.

Now you have convinced me even more that a TileMatrixSet should be dependent on a CRS. TMS SHALL support high resolution alignment. If not what are we doing?. In conclusion, we need epoch in the TMS definition!!.

[jerstlouis]

"We favor long/lat (CRS84) for a reason (tilecol corresponds to the "first axis")

But what makes tileCol the "first axis"? Because mathematically in 2D space x is horizontal and comes first? I don't think that is very straightforward. It comes after row in a Tiles API URL. At minimum, I think we need to fix that in the new variation because it is confusing. My tweaked variation in the PR says it is recommended because it is the namesake CRS of the URI :)

All starts by defining a CRS; normally a projected CRS. Only when you define a CRS you have a well defined Euclidean space with axis and an origin of coordinates.

The EPSG:4326 defines a geographic lat, lon CRS which can be realized in multiple ways. The lat, lon of the realization map to the lat, lon of EPSG:4326. This is precisely the same kind of mapping that I am suggesting is done here when a TileSet would pick a CRS, which has a precise mapping to the CRS used to define the TileMatrixSet tiled space.

Saying that the data define your CRS is wrong. The CRS exists in the first place and you reference your data to the CRS by adding coordinates to the data.

Yes that is true for the dataset, but this is first done completely independently from the TileMatrixSet.
And similarly for defining the TileMatrixSet, a bounding box is defined in a specific CRS and the tile space can be defined based on that bounding box CRS (that's why I say the pointOfOrigin refers to the BBOX CRS).

So if the tilespace is referenced using a tile space (the CRS of the BoundingBox that is getting tiled, e.g. CRS84), and the data is referenced to a precise realization of WGS84 (e.g. EPSG:9057) with an Epoch datetime, and there is a precise correspondence between the two CRS (EPSG:4326 as a datum ensemble is intended to be used with any realization / epoch defined in lat, lon), then it should be possible to use that TileMatrixSet to tile that data into a tileset.

The definition of TileMatrixSet changes completely and becomes just a mechanism to divide an space that has not been defined yet. The divisions are "floating" with no origin or position. It is possible to imagine, but this is not my old TMS. It is a new thing.

No, because what I am suggesting is that the BBOX has a CRS, so there is a precise CRS space that is being divided. But the precise mapping of that tile space to the coordinates (e.g. realizations, epochs, axis order, extra dimensions) has not been defined yet, so it would work with any of them -- and that is a very good thing in my opinion!

It is possible to imagine, but this is not my old TMS. It is a new thing.

It's 99% the same thing with this small tweak which I think is what will make it possible to support high precision mapping. :) Every single dataset is going to have a different data collection time etc., and everything keeps moving. So no two dataset would be using the same TileMatrixSet if the detailed CRS is fully defined in the TMS! And well-defined common TileMatrixSet is what makes things interoperable (e.g. the success of WebMercatorQuad because so many online mapping platforms use that one TMS specifically).

Now you have convinced me even more that a TileMatrixSet should be dependent on a CRS. TMS SHALL support high resolution alignment. If not what are we doing?. In conclusion, we need epoch in the TMS definition!!.

I think we need the CRS and the Epoch in the TileSet :) And make the TileMatrixSet flexible to support any CRS/Epoch for which its BBOX CRS is intended.

[joanma747]

"We favor long/lat (CRS84) for a reason (tilecol corresponds to the "first axis")

But what makes tileCol the "first axis"? Because mathematically in 2D space x is horizontal and comes first? I don't think that is very straightforward. It comes after row in a Tiles API URL. At minimum, I think we need to fix that in the new variation because it is confusing. My tweaked variation in the PR says it is recommended because it is the namesake CRS of the URI :)

It does not matter what is first in the URL. What we are talking about is that in mathematics X comes first and it is "horizontal" in diagrams. In TMS Tilecol is the horizontal one, so the "natural" order of coordinates is (x,y) and (tilecol,tileRow). That is why CRS:84 was defined in the first place. Having (lat,long) forces you to revers order when you go to (tilecol,tileRow).

About the other issue, I believe our opinions are clearly stated and there are two ways of proposed. Your proposal is that TileMatrixSets are not georeferenced and my proposal that they should be as it was in WMTS. Let's see what others say about this.

[jerstlouis]

It does not matter what is first in the URL. What we are talking about is that in mathematics X comes first and it is "horizontal" in diagrams. In TMS Tilecol is the horizontal one, so the "natural" order of coordinates is (x,y) and (tilecol,tileRow). That is why CRS:84 was defined in the first place. Having (lat,long) forces you to revers order when you go to (tilecol,tileRow).

In Physics (ISO 31-11 / ISO 80000-2:2019) (and for some mathematicians?), for spherical coordinates like lat, lon, polar angle (lat) comes first before the azimuthal angle (lon), like in ISO 6709.
In Mathematics 2D cartesian plane, Y is positive upwards, unlike most TMS tileRows.

CRS84 was defined because GIS computer scientists preferred thinking of lat, lon as 2D projected coordinates rather than as spherical coordinates -- but on a 3D virtual globe that doesn't make much sense.
And in computer science, "row, column" is often the preferred order, as video memory is usually organized, or as displayed in text editors, or compiler error messages.

What I am trying to say is that the current justification for saying WorldCRS84Quad is the default will probably not make sense to many.
The natural way I think of TMS tiles is always row, columns, and the natural way I think of geographic coordinates is lat, lon, so on both count I find it confusing :)

Your proposal is that TileMatrixSets are not georeferenced

I think I have to clarify my opinion further, because I never said "TMS should not be geo-referenced". My opinion is that a TileMatrixSet should be compatible with tileset data georeferenced in any CRS compatible with the CRS of the TMS's bounding box. And in this context compatible CRSes would be defined as:

• The data/tileset CRS is exactly the same as the TMS BBOX CRS, or
• The data/tileset CRS is the same CRS as the TMS BBOX but in other axis order (the tileset CRS order is what governs the tile data) and/or
• The data/tileset CRS is a member of the TMS BBOX CRS datum ensemble and/or
• The data/tileset CRS is simply adding extra dimensions to the TMS BBOX CRS

Also the Epoch is not part of the CRS, and defining a separate TMS for different epochs is not practical at all. Few / Common TMSes is what makes Tiles highly interoperable.

and my proposal that they should be as it was in WMTS.

WMTS implementations defined TileMatrixSets in different CRS than its selected WKSS. e.g. GoogleCRS84Quad WKSS TileMatrixSet defined as EPSG:4326. GoogleCRS84Quad WKSS specifies CRS84. The axis-order of the "data" was not really important because originally all "data" was 2D images in PNG and JPEG and always facing correctly whether CRS84 or EPSG:4326 was used.

From our WMTS:

<TileMatrixSet>
<ows:Title>GoogleCRS84Quad</ows:Title>
<ows:Abstract>GoogleCRS84Quad</ows:Abstract>
<ows:Identifier>GoogleCRS84Quad</ows:Identifier>
<ows:SupportedCRS>urn:ogc:def:crs:EPSG:4326</ows:SupportedCRS>
<WellKnownScaleSet>urn:ogc:def:wkss:OGC:1.0:GoogleCRS84Quad</WellKnownScaleSet>

and here:

        <TileMatrixSet xmlns:ows="http://www.opengis.net/ows/1.1">
            <ows:Title>WorldCRS84Quad (EPSG:4326)</ows:Title>
            <ows:Identifier>4326</ows:Identifier>
            <ows:BoundingBox crs="urn:ogc:def:crs:EPSG:6.3:4326">
                <ows:LowerCorner>-180.000000 -90.000000</ows:LowerCorner>
                <ows:UpperCorner>180.000000 90.000000</ows:UpperCorner>
            </ows:BoundingBox>
            <ows:SupportedCRS>urn:ogc:def:crs:EPSG:6.3:4326</ows:SupportedCRS>
            <WellKnownScaleSet>urn:ogc:def:wkss:OGC:1.0:GoogleCRS84Quad</WellKnownScaleSet>

WMTS was mostly used with PNG & JPEG, so at least in practice there was some ambiguity about the equivalence of CRS84 and EPSG:4326 in that context.

Since there was a minimal TileSet concept (TileMatrixSetLink), there was no place to communicate this extra information about the Epoch, and the "full" CRS with additional details such as axis order, extra dimensions, or particular datum realization. But we have this now to support vector tiles, multi-dimensional tiles and high precision mapping! :)

If I understand correclty, one idea behind CRSes is that they can be built in a hierarchical manner (e.g. datum realizations, compound CRS...). So a TMS defined in a "base" CRS should be compatible with derived CRSes.

[joanma747]

A section "TileMatrixSet CRS Compatibility" was added to the document to clarify when a TileSet can have a CRS that is different form the one in the TileMatrixSet. This was done in the 2021-06-10 meeting