Consider requirements from the Spatial Data on the Web Interest Group (SDWIG) about 2d-tile-matrix-set

[ghobona]

@joanma747 During the telecon today, @prushforth took an action to consider the previous suggestion and we will discuss it again next week Thursday (2021-08-05).

[jerstlouis]

Thanks @prushforth .
You could upload it in this Presentation folder I just created if you like.
I had also uploaded the version generated by GoToMeeting in the Recordings folder.

[prushforth]

I think we will have to keep the TCRS concept in place, as the differences in definition and intent are enough to warrant the separation. Thanks for a good discussion, though, and thanks for your attention in this matter.

-- PR

[prushforth]

Thanks @ghobona !

In MapML, we have created a "registry" of projection parameter information, that incorporates the gridset definition AND the EPSG/OGC CRS code.

It is an interoperability requirement, not just for MapML but for the Web at large as a 2D mapping medium, that the association of the set of parameter values identified by a (EPSG/OGC/OTHER) CRS identifier with the set of parameter values defining the tile gridset from what I understand: origin, resolutions, tilesize, bounds, be assigned an identifier that can become "well-known" or standard, and thus provide notional coordinate system interoperability based on a simple string comparison.

i.e.: if (inputIdentifier in knownIdentifiers) { retrieve tiles, render layers etc. }

"works" without having to compare the parameters individually.

The IOGP doesn't appear open to adding such parameters to their dataset, but I still believe it is vital to have standard definitions, and a registry that can provide stable visibility to those definitions.

[cportele]

@ghobona @prushforth - I must have missed something, but could you clarify what the issue really is? As far as I can see, the "projection parameter information" in MapML is similar to a tile matrix set and not like the old WKSS - the information includes an origin, a bounding box, the tile size. So, how/why would the WKSS solve a MapML interoperability problem and why can't you use the well-known tile matrix sets?

[jerstlouis]

@cportele @ghobona @prushforth

I feel like the common Tile Matrix Sets introduced in the TileMatrixSet standard, and registered in the TMS registry, and clarified in version 2, specifically address those needs:

origin, resolutions, tilesize, bounds, be assigned an identifier that can become "well-known" or standard, and thus provide notional coordinate system interoperability based on a simple string comparison.

That's exactly what the TileMatrixSet URIs in the TMS register do.

There is also a clarification on TileMatrixSet / CRS compatibility, concerning the ability of TileSets to re-use a common TileMatrixSet based on a different but related CRS (specifically members of a datum ensemble, additional dimensions, and flipped axis ordering). There is also the capability of specifying an epoch for dynamic datums as part of the tileset metadata.

[prushforth]

@cportele

So, how/why would the WKSS solve a MapML interoperability problem and why can't you use the well-known tile matrix sets?

Yes, the WKSS from WMTS was inadequate for MapML, so IIRC I suggested the well-known tile matrix sets be incorporated into the TMS specification, which thanks to @joanma747, it was. However, because a specification is not extensible, it doesn't fit the same role as a registry for this type of info.

I was not aware of the presence of these things in the OGC registry. I whole-heartedly support their inclusion and extension there. I believe this constitutes the "Convenience API" that I was looking for, although the reason I started talking about WKSS was to simply broach the subject of including these extra parameters / concepts into the EPSG dataset (again probably because I wasn't aware of your registry entries).

I became concerned this week that there was some notion of deprecating TMS gridset definitions, but I realize my confusion was a conflation of WKSS with TMS gridset definitions.

@jerstlouis

That's exactly what the TileMatrixSet URIs in the TMS register do.

These are good and I support the register concept.

One of the reasons to create a MapML "registry" of TCRS was to avoid URI / URN syntax, i.e. stick to simple string names that were memorable (shortish) and as far as possible, non-proprietary.

There is also a clarification on TileMatrixSet / CRS compatibility, concerning ... additional dimensions, and flipped axis ordering

But more than simply avoiding URIs and company names, the central reason that we incorporated the definitions in the MapML spec was the notion that axis order should be defined by the specification and never deviated from because of painful historical lessons in axis order confusion. I would say those lessons could also be applied to extra / fewer dimensions: if a program is reading a coordinates string, it needs to know how many numbers constitute a coordinate, and what the axis order of them is.

That comes back to why I believe this stuff is suitable for inclusion in the CRS definition, because I believe the (EPSG) CRS database shares the concerns with axis order and number of dimensions.

[joanma747]

After reviewing the concept of TCRS we believe corresponds to TMS and your requirements are already accounted for.
The TMS definitions could be part of the CRS definitions but until now the EPSG people, has not demonstrated interest in including tiling in the EPSG database.

The axes order is clear in TileMatrixSet as we follow the CRS order defined in the EPSG. Both Tilematrixset and tileset metadata has a new property to "repeat" the axes order for clarity (orderedAxes).

In the tilesetmetadata you can specify another CRS that can be more specific than the one in the TileMatrixSet

[prushforth]

The axes order is clear in TileMatrixSet as we follow the CRS order defined in the EPSG. Both Tilematrixset and tileset metadata has a new property to "repeat" the axes order for clarity (orderedAxes).

Perhaps I'm misunderstanding something, then.

Let's say I want to use a registered TileMatrixSet such as CanadianNAD83_LCC

If I find a TileSet somewhere, say in a GeoServer instance, as a client of that service, if I understand this section correctly, I cannot be sure that the axis order, or even that the CRS, is the same as that defined here by simply string-comparing the name/label of the TileMatrixSet with the name/label of the TileSet. Maybe I'm not clear on the distinction between TileSet and TileMatrixSet. My impression is that the former is a realization of the latter i.e. an instance. Is that correct?

[jerstlouis]

@prushforth Your understanding is correct.
The details about axis order, CRS realization, additional dimensions, and epoch, are specific to the TileSet.
So if your client cares about these, in addition to the tileMatrixSetURI, it should check the crs and epoch properties of the TileSet metadata to get more precise information about what data it will find in the tiles.

About the difference between TileMatrixSet and TileSet, to put it simply you get a TileSet from tiling geospatial data according to a TileMatrixSet.

The TileMatrixSet specifies the extent and resolution of each tile at a particular tile matrix / row / column.
How the data is organized can be defined at the TileSet and/or at the encoding level.

This facilitates the re-use of common TileMatrixSets, avoiding to create a completely different grid definition for the exact same tiling scheme but variation in content organization, which could then not be easily recognized as being the same grid.

CanadianNAD83_LCC is registered as EPSG:3978. If there is another compatible CRS (I'm not sure whether a flipped axis order version exists, but you could create e.g. a compound CRS adding a temporal value), a TileSet could be set up with:

"tileMatrixSetURI" : "http://defs.opengis.net/def/tilematrixset/OGC/1.0/CanadianNAD83_LCC"

but

"crs" : "http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/3978&2=http://www.opengis.net/def/crs/OGC/0/AnsiDate".

To summarize, a client recognizing well-known TileMatrixSets should do the following with the TileSet metadata
(in OGC API - Tiles found at at .../tiles/{tileMatrixSetId}):

1. String compare the tileMatrixSetURI to know what TileMatrixSet is used to partition & provide overviews of the data
2. Identify additional TileSet metadata details relevant to the application, such as the specific CRS (in terms of additional dimensions / axis order / realization) & epoch.

[prushforth]

After reviewing the concept of TCRS we believe corresponds to TMS and your requirements are already accounted for.

I don't believe so, because what TCRS enables is single-step recognition of the entire stack of coordinate systems involved; a second step is not necessary.

To summarize, a client recognizing well-known TileMatrixSets should do the following with the TileSet metadata
(in OGC API - Tiles found at at .../tiles/{tileMatrixSetId}):

1. String compare the tileMatrixSetURI to know what TileMatrixSet is used to partition & provide overviews of the data
2. Identify additional TileSet metadata details relevant to the application, such as the specific CRS (in terms of additional dimensions / axis order / realization) & epoch.

It seems to me that going to the trouble of making a registry of these definitions serves to make them a simple standard.

Adding additional comparison criteria to establish interoperability complicates the client logic and somewhat defeats the objective of the registry.

I think it would more interoperable to mint and register a new TileMatrixSet identifier for each combination of CRS / dimensions / axis order / realization and epoch, than to push all that onto the client.

Note that the definition of TCRS CBMTILE is close but not quite equal to CanadianNAD83_LCC, because we specified that the GCRS is CRS:83, whereas the CRS for CanadianNAD83_LCC is http://www.opengis.net/def/crs/EPSG/0/3978. Ideally, CBMTILE and others like it could literally be registered in the registry. I don't believe this approach would lead to proliferation of the registry content. At least no more, and perhaps less so than codes in the EPSG registry, because to be created it kind of implies that someone is actually defining and using a TileSet on the Web according to that definition.

This ties into my plea for considering this registry as a kind of convenience API for CRS, as found on the Web.

[jerstlouis]

@prushforth I am a bit confused by the CBMTILE defintion.
The tiles & content are defined according to a Lambert Conic Conformal projection?
In that case CRS:83 is just a base CRS on which EPSG:3978 is based, isn't it?
So how is CBMTILE different from CanadianNAD83_LCC?

Adding additional comparison criteria to establish interoperability complicates the client logic and somewhat defeats the objective of the registry. I think it would more interoperable to mint and register a new TileMatrixSet identifier for each combination of CRS / dimensions / axis order / realization and epoch, than to push all that onto the client.

This is not practical, because you may want to present together information from the same TileMatrixSet, but different realization, different epoch, different number of dimensions, data provided in different axis order, different encodings (some of which impose axis order or even CRS like GeoJSON). Having a common TileMatrixSet greatly simplifies this, as the client could deal with retrieving, caching and visualizing tiles from a single common TileMatrixSet.

The epoch is the most obvious example, because the epoch is a decimal number (a year with 2 digits decimals), and it would not make sense to register a different TileMatrixSet for every single epoch.
The epoch can be ignored if high precision is not important, but can be taken into account by the client to obtain high accuracy.
Same for realizations -- a high precision client could perform adjustments to take into consideration the different realization, while a simpler one will be happy to just overlay the tiles and have them aligned to a few meters precision.

In many cases the axis order is irrelevant (e.g. raster data or GeoJSON which specifies coordinates should always be in WGS84 lon, lat order). Additional dimensions may not be relevant to a particular client application.

See also #9 for a long discussion which after careful consideration resulted in what we have now.

[prushforth]

See also #9 for a long discussion which after careful consideration resulted in what we have now.

OK I'll review that before responding more; I am not really familiar with epoch or realization , so a bit behind on all that. I've never seen a tile cache that supports these concepts, as far as I can recall.

you may want to present together information from the same TileMatrixSet, but different realization, different epoch,
...
Having a common TileMatrixSet greatly simplifies this, as the client could deal with retrieving, caching and visualizing tiles from a single common TileMatrixSet.

For TCRS, epoch was not a requirement, but stability/reliability of axis order is a central consideration. The other central consideration is unification of grid definitions with stability of coordinate axis order under a single string identifier.

different number of dimensions, data provided in different axis order, different encodings (some of which impose axis order or even CRS like GeoJSON).

TCRS in MapML seeks the benefit of GeoJSON (RELIABLE axis order) without the constraint of binding the format to a single CRS.

It's really great to have had this conversation, because as I see it currently, version 2 of TMS doesn't respond to MapML requirements. I apologize for not having paid closer attention last year (I was quite busy otherwise).

The tiles & content are defined according to a Lambert Conic Conformal projection?
In that case CRS:83 is just a base CRS on which EPSG:3978 is based, isn't it?
So how is CBMTILE different from CanadianNAD83_LCC?

EPSG:3978 (LCC with particular parameters) specifies that it is based on EPSG:4269, but we wanted to be able to specify and couple the axis order within in the TCRS, so we define CBMTILE to declare that the underlying CRS, and the axis order you'll get data in, is CRS:83, which only varies from EPSG:4269 in axis order, mostly, IIUC.

[jerstlouis]

OK I'll review that before responding more; I am not really familiar with epoch or realization , so a bit behind on all that. I've never seen a tile cache that supports these concepts, as far as I can recall.

Thank you. Considering these dynamic CRSes allows high precision mapping, and is enabled by WKT2 for CRS and the work done for PROJ6 for example. These considerations were key for this update to the TileMatrixSet and the new TileSet metadata included in version 2.

For TCRS, epoch was not a requirement, but stability/reliability of axis order is a central consideration. The other central consideration is unification of grid definitions with stability of coordinate axis order under a single string identifier.

While I understand the importance of avoiding axis order confusion, conceptually the TileMatrixSet defines the extent and resolution of tiles and is agnostic of axis order, which is an aspect of encoding data inside those tiles. Since a particular encoding could enforce one axis order, while another encoding could enforce the opposite axis order, while other encodings could support both, the TileMatrixSet is not the concept at which a particular axis order should be absolutely enforced, as it could not handle that scenrario for example.

TCRS in MapML seeks the benefit of GeoJSON (RELIABLE axis order) without the constraint of binding the format to a single CRS.

If the MapML community wishes, it could define a TCRS as a well-known TileMatrixSet + a particular axis order and/or a specific TileSet CRS (but you may want to consider relaxing this to allow for different realizations of an ensemble CRS like EPSG:4326).

EPSG:3978 (LCC with particular parameters) specifies that it is based on EPSG:4269, but we wanted to be able to specify and couple the axis order within in the TCRS, so we define CBMTILE to declare that the underlying CRS, and the axis order you'll get data in, is CRS:83, which only varies from EPSG:4269 in axis order, mostly, IIUC.

• EPSG:3978 is projected Lamber Conic Conformal based on NAD83 with specific parameters ordered Easting, Northing
• EPSG:4269 is geographic based on NAD83 ordered Latitude, Longitude
• CRS:83 (assuming you mean http://www.opengis.net/def/crs/OGC/1.3/CRS83) is geographic based on NAD83 ordered Longitude, Latitude

The underlying geodetic CRS of EPSG:3978 is defined as EPSG:4269, and the fact that this CRS specifies Latitude, Longitude as the order has nothing to do with the order of the projected coordinates that EPSG:3978 specifies as being (Easting, Northing).

There is no need to throw CRS:83 into the mix, as it has nothing to do with EPSG:3978. CRS:83 is a Longitude, Latitude version of the geographic EPSG:4269 CRS. I see you include the "GCRS" in that column, but because it is only the base geodetic CRS, the axis order of that base CRS are of no consequence to the data, since the data gets projected e.g. to EPSG:3978 before axis order becomes relevant. I would have included the official base geodetic CRS as defined by the actual CRS being used instead (EPSG:4269).

So does CBMTILE really differ from CanadianNAD83_LCC, if they are both based on EPSG:3978 (which defaults to Easting, Northing), and tile the world the same? Since there probably is not any other equivalent CRS with a Northing, Easting order, I don't think CRS-related axis order issues would be a problem either for that particular tile matrix set.

Geographic coordinates where some prefer Longitude, Latitude and others prefer Latitude, Longitude are more likely to need two separate TCRS if you want to enforce a particular axis ordering. e.g. you could define WGS84 as WorldCRS84Quad with a Longitude, Latitude order, but WGS84_4326 with WorldCRS84Quad but a latitude, longitude order. But again that won't work if you want to allow any number of encodings (e.g. GeoJSON enforces longitude, latitude, so you couldn't use GeoJSON with WGS84_4326).

If you ask my opinion, axis order problems started the moment geographic coordinates started being flipped from ISO 6709 as if they were projected/cartesian coordinates. Not something that would have happened in 3D, but an irresistible tendency of programmers working with a 2D map :) (I have noticed that in our own team where a developer once told me my coordinates are mixed up because he is assuming them to be screen x, y coordinates but they were longitude, latitude!)

One outlier is EuropeanETRS89_LAEAQuad which is projected but defines the order as Northing, Easting, and we recently fixed issue #31 where we had gotten it wrong!

[ghobona]

@joanma747 I have re-opened this issue because the concerns of the SDWIG have not been addressed yet.

[prushforth]

The intent of the original version of this specification was to set in stone, so far as is possible, the relationship between the various coordinate systems involved in the creation and use of a tile cache as found in the wild. This notion is similar to how an EPSG code establishes the set of CRS involved in, for example, a given PCRS like EPSG:3978. If there's a new application of LCC that has different parameters, they will simply set up a new code. Axis order and number of axes are integral to any CRS, I understand.

The idea (for me, and for the MapML TCRS concept) was to establish firmly that a given tile set conforms to a known specification, similar to EPSG CRS, so that clients could be coded, in advance, to support a tile set which they came across, without having to consult metadata at run time. It was and is recognized that not all tile sets from now and into the future would be created according to a single archetype, which is why it is important, for interoperability to allow the creation of new standard tile matrix sets, hence a register.

The bottom line for me is that number of axes, and axis order, are integral to the intent of version 1.0, and not all use cases are covered by GeoJSON or MVT luckily sharing the axis order of an existing tile matrix set.

I've come to the conclusion, in reading other issues here that the intention of version 1.0 of this specification is not being upheld in version 2.0, so I would recommend making this into an entirely new specification, if that's preferable to accepting new TMS creation requests based on the version 1.0 concept of axis order, and number of axes, stability etc.

[jerstlouis]

SWG 2021-07-29:

• @prushforth presented the SDWIG concerns, centered on wishing to have a simple identifier that bakes in the CRS, number of axes and axis order, along with the TileMatrixSet. See also slides presented.
• I presented the rationale for the current state of the specifications (as previously discussed in the SWG -- see #9, and the TileMatrixSet / TileSet CRS compatibility clause, based on the concept that the TileMatrixSet simply defines how the Earth is partitioned for a particular CRS, but is agnostic of the data being tiled and the encoding of the resulting data, which is why TileSets (tiled data) are allowed to use compatible CRSes only differing by axis order, additional axes, or being a specific realization of a data ensemble. TileSets can also specify the epoch of the tiled data for a dynamic CRS.
• I pointed to examples such as the convenience of being able to re-use the same TileMatrixSet whether e.g. EPSG:4326 or EPSG:4979 is used, which simply adds an extra height above the ellipsoid, by having the CRS of the tiled data defined at the level of the TileSet (which itself references a TileMatrixSet). Some encodings may also override or prescribe the axis order, which would make it impossible to use certain combinations of TileMatrixSet & encoding.
• I also clarified that the CRS (and number of axes, axes ordering) of the tileset is assumed to be that of the CRS if not overridden at the TileSet metadata level.
• The previous suggestion that the SDWIG group could maintain a registry of TCRS referencing a well-known TileMatrixSet plus additional parameters baking in the CRS, number of axes and axes ordering was re-iterated. @prushforth will think about this and we will discuss it again next week.

[joanma747]

TCRS referencing a well-known TileMatrixSet plus additional parameters baking the CRS, number of axes and axes ordering was re-iterated. @prushforth will think about this and we will discuss it again next week.

I wonder about the "additional parameters". Do we have examples?. I was under the impression that a TCRS and a TMS where two names for almost the same concept. a TMS is a tiling schema on top of a CRS that seems to be the same as TCRS is.

By reading the lsit of TCRS https://maps4html.org/MapML/spec/#tiled-coordinate-reference-systems I see a 1 to 1 correspondence with the one defined in Annex D of 2D-TMS. the only thing that is different is the name.

[jerstlouis]

@joanma747 Correct:

OSMTILE: WebMercatorQuad
CBMTILE: CanadianNAD83_LCC
APSTILE: UPSArcticWGS84Quad
WGS84: WorldCRS84Quad

But in version 2 we introduced the CRS compatibility clause, allowing TileSets based on a TileMatrixSet using a CRS compatible to the TileMatrixSet differing only by:

• additional dimensions (e.g. EPSG:4326 / EPSG:4979),
• axis order (e.g. EPSG:4326 / OGC:CRS84),
• being a specific realization of the TileMatrixSet CRS datum ensemble (e.g. EPSG:4326 / EPSG:9057 (G1762))

The additional parameter I am suggesting for TCRS would simply be a CRS, which in the examples above would be the latter (the CRS from the TileSet metadata). This would make the TCRS sufficient to identify the number of dimensions, axis order and realization (point a,b,c,d below), but not the epoch. It would result in a TCRS registry with potentially a lot more entries than the TileMatrixSet registry.

If TileMatrixSets did not allow TileSets to use a compatible CRS with additional dimensions, axis ordering changes or different realizations:
a) standard GeoJSON (no prior arrangement, which is the case e.g. if you just share a tileset downloaded without metadata for example) as an encoding could only be used with WGS84 TCRS / WorldCRS84Quad TMS.
(Note that we should also have a permission for the CRS to differ at the encoding level, to allow a WebMercatorQuad tileset to advertise a EPSG:3857 CRS which can be used by some encodings, but GeoJSON fixed at CRS84. e.g. https://maps.ecere.com/ogcapi/collections/NaturalEarth:cultural:ne_10m_admin_0_countries/tiles/WebMercatorQuad/0/0/0.json is in CRS84, but https://maps.ecere.com/ogcapi/collections/NaturalEarth:cultural:ne_10m_admin_0_countries/tiles/WebMercatorQuad/0/0/0.mapml is in EPSG:3857)
b) height information for vector features could not be used with any of those CRSes
c) temporal information (as a dimension) could not be used with any of those CRSes (note that so far temporal / spatial CRS combinations are often defined on-the-fly, which makes pre-defining a dedicated TMS for each possible combination even more impractical)
d) the TileMatrixSet alone cannot indicate the specific realization of a datum ensemble
e) the TCRS / TMS alone cannot indicate the epoch at all, otherwise TMS would not be re-usable (epochs are decimal numbers)

To address a, b or c, this small set of TileMatrixSets would explode into a considerable number of TileMatrixSets to register, maintain and implement in clients taking a less generic approach (i.e. not able to handle arbitrary TileMatrixSet definitions).

Point d would require one TileMatrixSet per realization, and another for an unknown realization. That would significantly complicate handling datum ensembles such as WGS84, which is a large portion of geospatial data available.

Point e would make it impossible to use well known TileMatrixSets for dynamic CRSes.

[prushforth]

Please find attached my presentation from today's meeting. Should I upload this to the OGC portal somewhere?

Issue-Convenience-APIs.pptx

[prushforth]

I've tried to go through the suggested points, as well as concerns raised by @jerstlouis and @joanma747. I'm really trying to understand your view points, so that I don't talk past you. I have to say that I don't fully understand datum ensembles nor how epoch is used in practice, so that could be a problem here. The bottom line, I think is that I believe TMS should be treated like derived projected CRS, and should follow the axis order policy. It will result in more TMS registrations, but that was expected. If that's not going to happen, I think that we should close this issue and MapML/TCRS can continue on a separate path.

the TileMatrixSet defines the extent and resolution of tiles and is agnostic of axis order, which is an aspect of encoding data inside those tiles.

In MapML we implement the "tile" concept in two concrete ways:

1. <tile> element, which exists in an encoded document
2. <link rel="tile" tref=" url template here ">

In both cases the tile is expected to conform to the TCRS of the document, and is potentially represented by coordinate data, and the expected number of axes, and the order of the axes is defined by the TCRS, so not agnostic to axis order, number of axes.

Since a particular encoding could enforce one axis order, while another encoding could enforce the opposite axis order, while other encodings could support both, the TileMatrixSet is not the concept at which a particular axis order should be absolutely enforced, as it could not handle that scenrario for example.

This is why it should be possible to register new TileMatrixSets having different CRS with appropriate axis orders: so that an instance can declare itself according to a "well known" TMS; if a TileSet needs to override the CRS, it should follow the OGC 08-038r7 policy:

“any (OGC-conformant payload) SHALL state how the coordinate axis order is actually encoded…Further, any OGC payload should provide a CRS reference or CRS metadata” “The CRS SHALL be defined either by value, by reference, via a URL (current OGC policy), or by use of a URN”

You might question whether this policy should apply to TMS. My assertion is that TMS qualify as derived projected CRS under Abstract Specification Topic 2, so TMS should follow this policy.

I think it comes down to identifiers. If a TileSet follows what a registered identifier says, it should use the identifier. If you don't follow it completely, you have to fully specify the details of the CRS in WKT (or whatever, JSON preferably), you can't just override something as crucial as CRS that should not be expected to vary, unlike bounds or epoch which are expected to vary. The interoperability comes from the stable definitions of those identifiers.

The underlying geodetic CRS of EPSG:3978 is defined as EPSG:4269, and the fact that this CRS specifies Latitude, Longitude as the order has nothing to do with the order of the projected coordinates that EPSG:3978 specifies as being (Easting, Northing).

There is no need to throw CRS:83 into the mix, as it has nothing to do with EPSG:3978. CRS:83 is a Longitude, Latitude version of the geographic EPSG:4269 CRS. I see you include the "GCRS" in that column, but because it is only the base geodetic CRS, the axis order of that base CRS are of no consequence to the data, since the data gets projected e.g. to EPSG:3978 before axis order becomes relevant. I would have included the official base geodetic CRS as defined by the actual CRS being used instead (EPSG:4269).

So does CBMTILE really differ from CanadianNAD83_LCC, if they are both based on EPSG:3978 (which defaults to Easting, Northing), and tile the world the same? Since there probably is not any other equivalent CRS with a Northing, Easting order, I don't think CRS-related axis order issues would be a problem either for that particular tile matrix set.

CBMTILE does differ from CanadianNAD83_LCC because MapML documents always require axes to be presented in horizontal, vertical order (x,y), like GeoJSON (but more general, to support projected coordinates). MapML conforms to OGC 08-038r7_2017 recommendation Case 4, because we specify that if geographic coordinates (GCRS) are used they shall be presented according to CRS:83 conventions (long,lat). It's a bit of a hack, but there was no CRS:83 version of EPSG:3978 to use, so we tried to describe what to expect as best we can in one document. It would have been more ideal to actually have a version of EPSG:3978 that was based on CRS:83, so that we wouldn't have had to jump through hoops, but that was not the case.

OSMTILE also differs from WebMercatorQuad in a similar way. Because of our insistence on (long, lat), we had to specify the GCRS to be CRS:84.

But in version 2 we introduced the CRS compatibility clause, allowing TileSets based on a TileMatrixSet using a CRS compatible to the TileMatrixSet differing only by:

• additional dimensions (e.g. EPSG:4326 / EPSG:4979),
• axis order (e.g. EPSG:4326 / OGC:CRS84),
• being a specific realization of the TileMatrixSet CRS datum ensemble (e.g. EPSG:4326 / EPSG:9057 (G1762))

Again, if TMS were treated as CRS and conformed to OGC 08-038r7_2017 policy, TileSets could indeed differ from TileMatrixSet in these ways, only but they

"should provide a CRS (TMS) reference or CRS (TMS) metadata” “The CRS (TMS) SHALL be defined either by value, by reference, via a URL (current OGC policy), or by use of a URN”

If TileMatrixSets did not allow TileSets to use a compatible CRS with additional dimensions, axis ordering changes or different realizations:
a) standard GeoJSON (no prior arrangement, which is the case e.g. if you just share a tileset downloaded without metadata for example) as an encoding could only be used with WGS84 TCRS / WorldCRS84Quad TMS. (Note that we should also have a permission for the CRS to differ at the encoding level, to allow a WebMercatorQuad tileset to advertise a EPSG:3857 CRS which can be used by some encodings, but GeoJSON fixed at CRS84. e.g. https://maps.ecere.com/ogcapi/collections/NaturalEarth:cultural:ne_10m_admin_0_countries/tiles/WebMercatorQuad/0/0/0.json is in CRS84, but https://maps.ecere.com/ogcapi/collections/NaturalEarth:cultural:ne_10m_admin_0_countries/tiles/WebMercatorQuad/0/0/0.mapml is in EPSG:3857)

Note that these two versions of the same tile set could be described as OSMTILE, since MapML requires CRS:84 for GCRS coordinates, but also supports EPSG:3857 PCRS coordinates. GeoJSON requires a fixed CRS, so it shouldn't be a big issue for it to be bound to WorldCRS84Quad. FWIW this is central to why TCRS were created: binding the tiling structure and the CRS together into one concept (TCRS) doesn't lead to situations like where you're saying you're serving a WebMercatorQuad (Web Mercator uses EPSG:4326 internally) but the responses are encoded in CRS:84.

b) height information for vector features could not be used with any of those CRSes

That's true, but is it necessary? If it's necessary somewhere, shouldn't we have another TMS that is defined on a 3D CRS?

c) temporal information (as a dimension) could not be used with any of those CRSes (note that so far temporal / spatial CRS combinations are often defined on-the-fly, which makes pre-defining a dedicated TMS for each possible combination even more impractical)

Granted, but this is not (yet) a common use case on the Web. Why couldn't you provide such dimension information in a fully specified CRS WKT / JSON in the TileSetMetadata?

d) the TileMatrixSet alone cannot indicate the specific realization of a datum ensemble

Isnt' this taken care of at the CRS level? I believe EPSG:4326 is defined on such a concept. Aren't the maintainers of EPSG:4326 saying by defining this code as being valid for any of these datums, that they are interoperable? If a TileSet needs to be more specific in order to be higher precision perhaps, let it define the CRS completely.

Caveat: I am out of my depth here.

e) the TCRS / TMS alone cannot indicate the epoch at all, otherwise TMS would not be re-usable (epochs are decimal numbers)

Isn't epoch the time represented by the tiles? If so, I don't think it's appropriate for the TMS to specify the epoch, either. In that case the TileSet should have a property that specifies the epoch. Maybe I'm missing something here.

[joanma747]

After a long discussion we realized that the language of the to standards looks different but in practice TMSs can be used in MapML. We have to take into account that the axes order defined by the CRS is honored the TMS but MapML forces the horizontal-vertical order instead.
We decided to close the issue respecting the existing differences that can be overcome with simple code.