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?
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.
ghobona
commented
3 years ago
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 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.
Originally posted by @prushforth in https://github.com/opengeospatial/2D-Tile-Matrix-Set/issues/36#issuecomment-880970960