opengeospatial / 2d-tile-matrix-set

OGC 2D Tile Matrix Set & TileSet Metadata standard

Welcome to OGC's Github page.

2d-tile-matrix-set's Issues

Consideration of resolution separately from tiling (no resampling & one other use case)

Potentially, the concepts of tiling and resolution/scale/Level of Detail in TMS could be separated.

e.g. you could instantiate the GNOSISGlobalGrid with 256 tileMatrixWidth x 256 tileMatrixHeight, but the exact same tiling could be used with 512 tileMatrixWidth x 512 tileMatrixHeight.

In addition to enabling the creation of different variations of the grids where the tile matrices are associated with different amount of data & different resolution, an important use case for this would be the ability to override the tileMatrix / tileWidth (from which the cellSize / scaleDenominator are derived) at the TileSet's tileMatrix level. This would in turn allow to preserve the original data without any resampling at the finest zoom level (and avoid overhead). e.g. tiling the data according to the grid at the level avoiding data loss may result in 240 x 230 cells, and that could directly be the size of the tiles, instead of having to oversample to 256 x 256 at the finest zoom level.

This use case is particularly important for storage and coverages in particular.

This also has me thinking whether Cloud Optimized GeoTIFF (COG) for data of an arbitrary resolution, avoiding re-sampling, is suitable as a back-end / efficient 1-to-1 tile mapping for an arbitrary tile matrix set? To use COG as a back-end and also preserve the original non-resampled data, we would also need the COG most detailed level tiles to match the special finest level tile size, but the overviews would still use the regular lower-resolution TMS, since those could be resampled.

Remove tileMatrixSetDefinition left-overs (Req 17, JSON Schema description)

In TileSetMetadata remove mention:

(an optional tileMatrixSetDefinition pointing to a local definition can also be provided)

Since this is now addressed by addressed by a link with http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme relation type, and adds confusion. The link is required and addressed in a separate requirement.

There is also another left-over in the description of the TileMatrixSet JSON Schema.

Create the diagram representing tiles in columns.

To introduce more dimensions we can think on 3 levels:
1.- Columns on top of a 2dTles (CDB uses this)
2.- Columns divided in "blocks" on topo fo 2d tiles that will be described by a 3Dtilematrix
3.- Columns that changes the number of divisions in the same way as the 2D in each scale change
(and consider this also more dimensions for time and ...)

Jerome's version.

1. Extend in other dimension; Use TMS as is, reduce content with level
2. Add slices in other dimension (but overviews still based only on other dimensions)
3. Change the number of slices in other dimension as well at lower levels (turning into octree or hyperoctree) hexadecitree

We could to add a comment on the relation with 3DTiles and what they do with their "boxes"

Include tileMatrixSetURI as a field in the /tileMatrixSets resource

Day 3 of 2021-05 Sprint

The /tileMatrixSets resource should provide information about the identity and the tileMatrixSetURI of the TMS.

The id does not need to match the tileMatrixSetURI.

If the TMS is registered in the Definitions Server, the tileMatrixSetURI should reference the TMS.

Section 5.3.3

CRSum...is this an error? Where does this come from?

Question about optional tileMatrixSetDefinition

I see that tileset metadata is required to have only one of the following: tileMatrixSetURI, tileMatrixSetDefinition, or tileMatrixSet. It looks like the tileMatrixSetURI do not resolve to a tile matrix set definition. I'm curious what the thinking is around how a client might determine the tile matrix set definition given a tileMatrixSetURI.

If a client is built with definitions for all of the tile matrix sets registered with the OGC NA definition service, this only works until a new tile matrix set definition is registered. Meaning all client libraries would need to be updated, and all clients would have to be redeployed any time a new tile matrix set definition is registered.

It would be more forward compatible if the spec required that servers host tile matrix set definitions even if they conform to a definition registered with the OGC NA definition service. This seems like a minor burden on server implementations (to always host the definitions for the tile matrix sets that they support), and it would allow clients to continue working even after new tile matrix sets are defined and registered.

If the tileMatrixSetDefinition (or tileMatrixSet) were required any time tileMatrixSetURI were used, clients that already know the definition for a specific URI could skip fetching the definition. At the same time, clients that come across a tileMatrixSetURI that is not recognized (perhaps it was registered after the client was built), the client could rely on being able to fetch the tileMatrixSetDefinition.

If the spec required one of tileMatrixSetDefinition or tileMatrixSet and said tileMatrixSetURI was optional, clients could optionally skip fetching the definition where tileMatrixSetURI was available and recognized, but could always rely on being able to get the definition (in case tileMatrixSetURI is not recognized).

TMS WorldMercatorWGS84Quad.json issues

in http://schemas.opengis.net/tms/1.0/json/examples/WorldMercatorWGS84Quad.json

1. In addition to "tileHeight" : where there should be "tileMatrices" : (also, other VTP2 participants currently have tileMatrix, but I believe we had previously agreed this should be plural),
   the topLeftCorner for each level should be e.g.

[ -20037508.3427892439067, 20037508.3427892439067 ]

rather than

[-180, 90],

(as it is in WebMercatorQuad, another projected CRS tiling scheme).

http://ows.geo-solutions.it/geoserver/ogc/tiles/tileMatrixSets/WorldMercatorWGS84Quad?f=json
https://services.interactive-instruments.de/t15/daraa/tileMatrixSets/WorldMercatorWGS84Quad?f=json

2. Also, the scales and the matrixWidth are all off by a factor of 2.

Pizel is pixel

on behalf of James Passmore - BGS via Requests [email protected]
Fri 05-Nov-21 13:53

Page 26 has "Since services cannot predict the pizel size"

should be "pixel"

James Passmore

Make TileSet crs mandatory

Suggesting to make the TileSet crs property mandatory to avoid potential confusion associated with it defaulting to the TileMatrixSet CRS.

It is currently stated that the same common registered TileMatrixSet CRS can be defined using e.g. either CRS84 or EPSG:4326, and the difference in axis order only affect the the tile matrices' pointOfOrigin coordinates (we have one such example for WorldCRS84Quad).

some implementers prefer to define the previous TileMatrixSet using the CRS http://www.opengis.net/def/crs/EPSG/0/4326. The definition is the same as the variant defined using http://www.opengis.net/def/crs/OGC/1.3/CRS84 except that CRS coordinates are expressed in latitude, longitude order, affecting the PointOfOrigin and the BoundingBox encoding only. For most practical purposes, both variations are equivalent because a TileMatrixSet primarily defines the tiling structure as well as the scale/resolution at each tile matrix, rather than how the data within each tile is stored.

However if no CRS is specified for the TileSet, that TileMatrixSet CRS is the default, and if coordinates in the encoded tiles rely on the TileSet CRS axis order, the axis order is left undefined.

Making the TileSet CRS mandatory avoids this issue.

An alternative might be to clarify that the TileSet CRS (when left undefined) defaults to the CRS of the official registered definition even if the local definition differs (e.g. CRS84 in the case of WorldCRS84Quad).

Other Admin Changes

Please look at Requirement #7, which is blank.

Also, look at Annex D, there is a note on Web Mercator regarding NGA's stance. The URL is not active. Also, they (NGA) does allow Web Mercator for visualization, it is not recommended, but they have softened their stance somewhat. It is still not allowed under CJCSI 3900.1 D, so now the US has conflicting guidance on Web Mercator.... :-)

well-known-scale-set URIs

I just noticed that the well-known-scale-set URIs have changed between WMS 1.0 (OGC 07-057r7) and OGC 17-083r2. In the former it's "urn:ogc:def:wkss:OGC:1.0:GoogleMapsCompatible", while in the latter it's "http://www.opengis.net/def/wkss/OGC/1.0/GoogleMapsCompatible". Was this change made intentionally? Which are WMTS servers now supposed to report? Do client applications now need to check for both forms? This issue, and how to deal with it, needs to be addressed.

In the future, we aught to be more careful about changing well-known identifiers like this just to adapt to the flavour-of-the-month. It wreaks havoc with interoperability.

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

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.

Change the TMS examples to include the new cornerOfOrigin and pointOfOrigin

This is new in TMS 2.0

minus and plus infinity

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)

Add a reference to Topic 21 (DGGS) - Part 4 - Axis-Aligned

The TileMatrixSet Variable Width tile matrices allow to define Discrete Global Grid Systems as defined by Topic 21 - Part 4: Axis Aligned, such as the CDB Global Grid and GNOSIS Global Grid.

Although both of these grid attempt to approximate equal area, they cannot fully qualify as a DGGS under Topic 21 - Part 1, because there is a requirement that cells of a given level are of equal area within a 1% margin.

Variable width conformance class is missing from Section 2 - Conformance

The following URIs should be listed in Section 2: conformance:

• http://www.opengis.net/spec/tms/2.0/req/variablematrixwidth
• http://www.opengis.net/spec/tms/2.0/req/json-variablematrixwidth
• http://www.opengis.net/spec/tms/2.0/req/xml-variablematrixwidth

Make `dataType` an extensible list rather than a restricted enum

In JSON Schema, enums are not extensible, but we foresee additional data types beyond map, vector and coverage and should not restrict these. Additional values are already being discussed for e.g. 3D models and point clouds.

In OGC API - Styles ( opengeospatial/ogcapi-styles#30 ) we changed the enum to examples.

For dataType remove the enum and move the values to examples. This is not a final, definitive list. Add point cloud, mesh.

MapML TCRS and 2D-Tile-Matrix-Set v2.0 incompatibility

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.

Originally posted by @prushforth in #36 (comment)

6.1.5 Reference to i dimension

As reported by Carl:

In clause 6.1.5 is the sentence:

The solution consists of reducing the number of tiles (matrixWidth) in the high latitude rows and generating those tiles with a compressed scale in the i dimension (see Figure 5).

Checking Figure 5, there is no reference (label) to the "i dimension".

And additional observations from myself:

Could we simply refer to the dimension as the "longitudinal dimension" or similar term to avoid confusion in 6.1.5?
Is this a result of Figure 5 that was updated, or shifted figure numbers and the reference should now be to Figure 7?

There are references to 3 discrete indices i, j, and tile matrix identifier in section 6.1.4 and in Figure 7.

6.1.4 also has this sentence:

In a two-dimensional space, a tile is identified by 5 discrete indices that are named: tile row, tile column, tile matrix identifier, i and j.

That doesn't sound right to me, a tile can be identified only by the 3 indices tile matrix, tile row and tile column. Should this be saying cell rather than tile?

In this 6.1.4 section, it seems that i and j are used for 2 completely different meanings:

• In the first bullet, i and j seem like coordinates inside a single tile
• In the second bullet, i and j seem like coordinates inside a whole tile matrix

Figure 7 seems to illustrate the first bullet with a) and the second with b), but the figure for b) calls coordinate i' and j'.
It would be helpful to replace the bullets by a) and b) if that is the case, and be consistent about i vs. i'.

We need an Epoch in the tileSet metadata

Epoch is generally not part of the CRS.

Do we still need the Well Known Scale Set?

Now that we have Common TMSs in Annex D and we want to encourage people to use them, do we still need he WKSS concept in annex C?. The link to a WKSS is just informative as the actual values fro the scales are repeated in any TMS.

After discussing it in telco 2021-02-25 we still believe they provide connection to the old WMTS and can still be included.

We will include a paragraph to explain that WKSS this was included fro interoperability but now the good practice is use common TMSs and TMSLimits if necessary.

Clarify history of TMS URNs and URLs

From: Fri 05-Nov-21 13:53

[email protected] on behalf of James Passmore -

Page 35 has

"In WMTS 1.0 a URN was used as a reference to a well-known scale set. Later, OGC adopted URIs (instead of URNs)"

A URN is a URI, so OGC couldn't have adopted URI's instead of URNs.

perhaps instead:

"In WMTS 1.0 an URN was used as a reference to a well-known scale set. Later, OGC adopted HTTP URIs"

Consider using resolution instead of scaleDenominator

I know that there is a legacy of scaleDenominator in OGC specs, but I'm wondering if there has been any discussion about starting fresh on this spec.

The concept of "scale" doesn't apply well to digital maps. Broadly speaking, a rendering client may not be able to determine the physical pixel size of a display device. Newcomers to the Tiles spec may scratch their heads for a while trying to figure out how the server is supposed to know the pixel size of the display if the client can't even reliably determine it. After digging for a while through other OGC specs, they may discover the magic 0.28 mm "standardized rendering pixel size" and copy this into their code.

Since 0.28 mm will rarely (never? - try to find a 90.7 PX / inch device here http://screensiz.es/) be the physical size of a pixel, the scaleDenominator has no real meaning and only serves as a source of confusion for those that assume it does.

Instead of using the confusing scaleDenominator and requiring that implementors discover the magic 0.28 mm number, tile levels could be described in terms of resolution (number of map units per pixel). It is the resolution that a client needs to know in order to render tiles on a map.

Consider include a Well Know Text description of the CRS

(The origin of this entry is the CRS.DWG meeting in September 2020 but the need was discussed in CRS.DWG in Banff)

The idea is that CRS's evolve over time and the move. This means that the reference to a CRS id is not enough if you need that level of precision.
In practice providing an PROJ WKT entry (string) solves the problem as you can fully describe you CRS by yourself.

There is an emerging encoding alternative in JSON with some links documented here. But this will only work with we define the UML property as "any" and allow for a JSON object in the JSON encoding.

Here's what EPSG:32642 would look like in PROJJSON https://henzuru.io/v1/crs/EPSG/32642
https://proj.org/specifications/projjson.html
https://proj.org/schemas/v0.2/projjson.schema.json <-- openapi schema

Consider a long list of editorial changes provided by Carl Reed

CNRs_edits_and_comments_on_OGC_Two_Dimensional_Tile_Matrix_Set_and_Tile_Set_Metadata_17-083r3.docx

conceptual model for tiled feature data?

In the current draft, there are a number of references to tiled feature data in Section 6. However, it is unclear how this feature is to be implemented. We have a conceptual model (OGC Simple Features) for feature data. We have a conceptual and logical model (OGC Tile Matrix Set) for tile pyramids. However, there is no known conceptual or logical model for tiled feature data. My impression is that Implementers will expect to see this gap filled before concurring on OAPI-T as a standard. If this gap is not to be filled by this SWG, then who?

This gap in the OGC baseline also affects GeoPackage but I am bringing this up here because this SWG is closer to having a formal definition of this capability.

I suppose this is an escalation of opengeospatial/ogcapi-tiles#54.

Add stylableLayerSet to TileSet metadata

In a conversation with Jerome he proposes:

9. The TileSetMetaData from the Vector Tiles Pilot had stylableLayerSet, which was an important concept allowing to match a data layer with styles ascribing to the same stylable layer sets.
   I would like to see this included here... Maybe it could be a 0..* . An example would be "stylableLayerSets" : [ "NSGOpenStreetMapTopographicDataStore" ]

I'm trying to understand. So what should contain? style names or layer names?

Neither! It's an identifier that both styles and layers can associate with.
This way a publisher can qualify their data with a StylableLayerSet, and a cartographer can qualify their styles with a StylableLayerSet.
And then it can be used to see which layers work with which styles.
If they both say "GeoFabrikOSM", then you know they work together.

If stylableLayerSet is added, where the list of stylableLayerSet is defined?. Or there is no need for this list?.

Is `EuropeanETRS89_LAEAQuad.json` example right ?

👋 First I hope this is the right place to raise the issue/ask question.

I've been catching up with the proposed TMS specs and it's really interesting.

Looking at the examples (tms/json) I found the EuropeanETRS89 tms which seems to have been copied form the http://schemas.opengis.net/tms/1.0/json/examples/ and updated to match the new specs.

2D-Tile-Matrix-Set/schemas/tms/2.0/json/examples/tilematrixset/EuropeanETRS89_LAEAQuad.json

Lines 7 to 16 in 84f4ed9

	"lowerLeft":
	[
	2000000.0,
	1000000.0
	],
	"upperRight":
	[
	6500000.0,
	5500000.0
	]

☝️ as mentioned in vincentsarago/TileMatrixSets#1 the coordinates for the origins seems to be in a incorrect order. Maybe this is wrong but would love info on this. 🙏

Thanks

Feel free to close this issue if it's not the right place

Section 8.2.1

Because you in section 8.2.1. you are talking the requirements class, shouldn't the following be upper camel case?

"Requirements class tilematrixsetlimits establishes..."

register new rel types in OGC NA

Register link relation types dataset, geodata and tiling-scheme with http://www.opengis.net/def/rel

Consider all the metadata elements described in "Vector Tile pilot 2: TileSet Metadata ER" to expand the current suggestion for TileSet metadata

See this issue to know more about the actual change.

opengeospatial/ogcapi-tiles#43

add what we can extract form the right part of Figure 8 in http://docs.opengeospatial.org/per/19-082r1.html

Add the CDB Global Grid as a defined tile matrix set

The CDB Global Grid combines the CDB Zones with the CDB Level of Details to define both using the 2DTMS Variable Width Tile Matrix Sets conformance class.
A definition is available here:
https://maps.ecere.com/ogcapi/tileMatrixSets/CDBGlobalGrid (JSON).
It also provides an alternative practical example of variable width tile matrices.

Re-using the 2DTMS standard in CDB would greatly simplify understanding of these concepts.

Consider introducing tilerow axes orientation in 2D-TMS 1.1

See that mapbox is still supporting both orientations. They call them "xyz" or "tms".

See: https://github.com/mapbox/tilejson-spec/tree/3.0/3.0.0#315-scheme

5.3.2. Description, Title and Keywords

In section 5.3.2, there is a UML diagram with "Abstract" in it (Figure 2). I believe that that should be "description" to match table 1 below it.

Consider including well-formed examples

It would be helpful if this repository included the JSON and XML examples of complete, self-contained and inter-linked, documents in JSON and XML encoding, e.g. those available at http://schemas.opengis.net/tms/1.0/json/examples/

Change `geometryType` to `geometryDimension` integer

We decided to follow this approach in OGC API - Styles ( opengeospatial/ogcapi-styles#30 ) to avoid confusion with the Simple Features geometry types, which e.g. has single / multi flavors. We should re-synchronize the changes here.

Change geometryType to geometryDimension (integer) with values: 0 (points), 1 (curves), 2 (surfaces), 3 (solids), null/not existent (mixed dimension/unknown)

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

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.

Annex J - Additional dimensions - bad grammar sentence

At https://docs.opengeospatial.org/DRAFTS/17-083r3.html#_no_explicit_tiling_of_extra_dimensions the sentence

Despite not being structured as tiles, extra dimensions could still be subset if the APIs such as the subset (trimming or slicing) and datetime (temporal slicing) query parameters.

is missing words since f2c9f7f.

Could be e.g.

Despite not being structured as tiles, extra dimensions could still be subset if the API supports a subsetting mechanism such as the subset (trimming or slicing) and/or datetime (temporal slicing) query parameters.

Add RDF

I was asked to produce some RDF for GeoPackage in conjunction with conceptual model activity. Since GeoPackage now aligns to this standard, it seemed sensible to make RDF for this standard and import it. It can sit next to the other schemas.

Remove dependency form OWS Common 2.0 BoundingBox

Remove the small dependency on OWS Common 2.0 and copy the definition of BoundingBox in the spec directly

How to JSON encode geometry and properties in the layer description in TileSet metadata

In JSON encodings proposed by Jerome

1. We should probably have an enumeration type for geometry type,
   suggesting:

• points
• lines
• polygons

2. For the layer properties, as previously discussed we should
   coordinate this with the general question of queryables / presentables /
   schema, and perhaps additional things specified in that layer metadata
   could also be things specified by OGC API - Common Part 2 either at the
   extended /collections/{collectionId} end-point, or at a sub-end-point
   like /collections/{collectionId}/{something}.

Our current implementation of queryables uses "id" rather than "name",

In my opinion it should be better to have a
"schemas" : {
}
(exactly as OpenAPI)

The content of "schemas" is under discussion. One alternative could be to have a a full GeoJSON schema personalized to the feature types. These mean, defining a geometry and a property sections and setting the geometry to a single geomentry (e.g. LineString) and the properties to the actual property names and types.

Add OGC: OGC 19-014r1: Core Tiling Conceptual and Logical Models for 2D Euclidean Space (2020) as normative reference to 2D-TMS

Already said

Motion to send for OAB Review

SWG 2021-08-12: Motion to send the 2D Tile Matrix Set and Metadata standard for OAB review in preparation for public comments
Motion: Jeff Harrison
Second: Jerome St-Louis
Discussion: None
There was no objection to unanimous consent.

CC @ogcscotts @joanma747

Consider to replace TileMatrixSetLink with TileSet metadata and change the name of the standard

See this issue to know more about the actual change.
opengeospatial/ogcapi-tiles#43

consider this too:
#10

TileMatrixSet issues

1. E.3.2 -- what is normally "tileMatrix" : [ ... ] elsewhere, here is "tileHeight" : [ ]

2. In the JSON schema for WorldCRS84QuadVariableWidth.json , this defines a nice variable width matrix set, but the identifier is "WorldCRS84Quad". Shouldn't this be "WorldCRS84QuadVariable" or something else?

3. The JSON examples in the document use the fancy quotes, so if one copy-pastes an example, it will not be valid JSON.

4. "tileMatrix" is a property that defines an array of multiple TileMatrices.
   We've been using "tileMatrices" for a while on our service and I thought we had reached an agreement to use the plural form.
   It would be nice to standardize on how to define such a property with multiplicity...
   I think the standard approach for JSON schemas should be in XML corresponding to "tileMatrices" : [ { "type" : TileMatrix", ... } ] in JSON

   If I do tileMatrix = something, I expect to be defining ONE tile matrix, not an array. Just like when writing in XML I define one tile matrix in there.

5. I find the "Type" suffix enum values for the classes used with the "type" property problematic. I don't believe such a suffix is typically used, or wanted.
   For example in GeoJSON, "type" : "FeatureCollection". There is no "Type" suffix.

The main purpose of such a standard type property is support polymorphism, where an expected object could be a number of different things.
So when we do use Type, we can for example use reflection to find the class that "type" identifies.
(this is actually not needed here at all because the same object type is always expected, so type is actually superfluous).
So if the type is "TileMatrix", we can look up the TileMatrix class. This breaks if the type is set to "TileMatrixType".
In ECON (http://ec-lang.org/econ/), our superset of JSON compatible with eC instantiation syntax, the type can naturally be specified before the curly braces, e.g.:

tileMatrices = [ TileMatrix { identifier = 0, ... }, TileMatrix { identifier = 0, ... } ]

Also conceptually, if the type of an object is a "TileMatrixType", then it is not a TileMatrix, it is a type of TileMatrix
We can't directly look up the UML class in a diagram either...
I don't understand why a suffix would be wanted here, there is no namespace collision...

I realize TMS is now a published standard (but arguably no published standard yet references it! ), but I think these are important concerns, and it would be nice to clarify the approach, also for future JSON schemas...
I wish I noticed and commented about this earlier (in fact I may have but didn't have time to check status before publication).

Consider requirements from the Spatial Data on the Web Interest Group (SDWIG)

The SDWIG has requirements for Well Known Scale Sets (WKSS), driven by the Maps4HTML initiative. The details are described at w3c/sdw#1237

The OGC API - Tiles SWG should discuss the requirements of the SDWIG to determine:

• if the current version of the 2D TMS addresses the requirements
• how the next version of the 2D TMS should address the requirements

Cc: @joanma747 @jerstlouis @prushforth

The following resources are relevant for the discussion:

• Descriptions of example WKSS in the 2D TMS standard http://docs.opengeospatial.org/is/17-083r2/17-083r2.html#56
• Registrations in the OGC Definitions Server http://www.opengis.net/def/wkss/OGC
• Definitions of common Tile Matrix Sets, as specified in the 2D TMS Standard http://docs.opengeospatial.org/is/17-083r2/17-083r2.html#61
• Registrations in the OGC Definitions Server http://www.opengis.net/def/tms

Change spec element URI in Clause 5

Clause 5 says the "The normative provisions in this Standard are denoted by the URI http://www.opengis.net/spec/TileMatrixSet/2.0"

However, specification element URIs in Clauses 2, 6, 7, 8, and Annex A all start with http://www.opengis.net/spec/tms/2.0

Since there are more instances of the /tms URI, please change the URI in Clause 5 to match the others.

Fix dependency URI in Clause 6.2.1

Clause 6.2.1 mentions a dependency http://www.opengis.net/spec/tile-model/1.0/req/tile-set-scheme

I think this URI was meant to be referencing the Tile Set Scheme requirements class of the Abstract Specification Topic 22.

If that is the case, then the dependency URI in Clause 6.2.1 of the 2D TMS should be http://www.opengis.net/spec/2d-tile-model/1.0/req/tile-set-scheme

Create a "registry" folder with the "master" copy for the "NA" to harvest.

We will create this folder with the "master" copy for the "NA" to harvest.

/registry/2.0/ with the json encoding following the 2D-TMS 2.0 encoding

a script could be create to translate the json into xml automatically.

The "2.0" subfolder will NOT be included by the "NA" urls and the "NA" will expose all versions of the encodings under a single URL and theoretically a "version=" parameter could be included in the future to return other versions.

should `id` and `uri` be WGS1984Quad

in 👇

2D-Tile-Matrix-Set/schemas/tms/2.0/json/examples/tilematrixset/WGS1984Quad.json

Lines 2 to 4 in 3a858d7

	"id": "WorldCRS84Quad",
	"title": "EPSG:4326 for the World",
	"uri": "http://www.opengis.net/def/tilematrixset/OGC/1.0/WorldCRS84Quad",

I think the ID should be WGS1984Quad (I think the URI too, but then it will point to an invalid URL for now 🤷 )

Happy to make a PR if 👍