Question about optional tileMatrixSetDefinition

[tschaub]

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).

[jerstlouis]

@tschaub The intent is that the TMS register TMS entries should resolve to a TileMatrixSet definition.

In the meantime, those TileMatrixSets currently registered are all defined in the 2D TMS standard.

I think it would make sense to at least make it a recommendation that the server also provides a tileMatrixSetDefinition locally.

The tileMatrixSetURI is still important for simpler clients implementing support only for specific TMS without the capability to parse, understand and support arbitrary TMSes.

[tschaub]

I agree about the benefits of tileMatrixSetURI as an identifier for clients that are built with an internal mapping to the corresponding tile set definition.

However, I think the spec overlooks the drawbacks of making the tileMatrixSetDefinition or tileMatrixSet optional. Unfortunately, a mere recommendation to include one or the other is not enough (a reliable client can only depend on spec requirements).

If the idea is that eventually all tileMatrixSetURI will resolve to a tile matrix set definition, there are additional concerns to consider:

• Mixed-Content: The current http protocol URI (e.g. http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad) will likely be blocked by clients hosted with the https protocol.
• CORS: The OGC hosted tile matrix set definitions, even if available via https, would need to be configured to allow cross-origin requests from all origins and properly handle CORS-preflight requests.

If the spec required that either tileMatrixSetDefinition or tileMatrixSet be included, a client would be guaranteed a way to understand the tile matrix set. This would still allow for clients to take advantage of the optional tileMatrixSetURI if it were available. The additional requirement would mean that servers would need to provide access to the tile matrix set definition. This minor additional requirement comes with the benefit of being able to deploy client/server implementations that are free from mixed-content or cross origin resource sharing issues.

In short, I think this would make for a better tileSet.json spec:

{
  "$schema": "https://json-schema.org/draft/2019-09/schema",
  "title": "Tile Set Metadata",
  "description": "A resource describing a tileset based on the OGC TileSet Metadata Standard",
  "allOf": [
    {
      "type": "object",
      "properties": {
        // additional optional properties here...
        "tileMatrixSetURI": {
          "description": "Reference to a Tile Matrix Set on the OGC NA definition server (http://www.opengis.net/def/tms/). Required if the tile matrix set is registered on the definition server.",
          "type": "string",
          "format": "uri",
          "examples": [
            "http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid"
          ]
        }
      }
    },
    {
      "description": "At least one of 'TileMatrixSet' or 'TileMatrixSetDefinition' SHAL be provided",
      "anyOf": [
        {
          "type": "object",
          "required": [
            "tileMatrixSet"
          ],
          "properties": {
            "tileMatrixSet": {
              "description": "Tile matrix set definition",
              "$ref": "tileMatrixSet.json"
            }
          }
        },
        {
          "type": "object",
          "required": [
            "tileMatrixSetDefinition"
          ],
          "properties": {
            "tileMatrixSetDefinition": {
              "description": "Reference to a tile matrix set definition following the Tile Matrix Set Standard. Optional for tile matrix sets defined on the OGC definition server; required for custom Tile Matrix Sets.",
              "type": "string",
              "examples": [
                "http://data.example.com/tileMatrixSets/WorldMercatorWGS84Quad"
              ]
            }
          }
        }
      ]
    }
  ]
}

[jerstlouis]

@tschaub Thank you for bringing up this issue -- I understand your additional concerns. @joanma747 I suggest we discuss this at our next OGC API - Tiles SWG meeting (Thursdays 10:30 AM Eastern)

[joanma747]

We agreed 2021-06-03 on requiring tileMatrixSet or tileMatrixSetDefinition independently of having a tileMatrixSetURI.

[joanma747]

Change applied everywhere.