fix: remove hardcoded enum-ids which should be examples

[CommanderStorm]

Currently, in a few places the IDs of resources are quite restrictive while in others they are not.

I think, the restrictiveness is a bug in the openapi sepc, as nowhere in the big spec the restrictions that are currently in place come up, or at least I did not find them.

Note

this also affects https://github.com/opengeospatial/ogcapi-tiles/blob/master/openapi/api/tileMatrixSets.json , but there it might actually not be a bug, since I don't know why one would want anything other than WebMercatorQuad

[jerstlouis]

At least some aspects of the OpenAPI definition, obviously those you highlighted, should not be taken as normative.

The OpenAPI definition as a whole is an example for a particular possible implementation. There are different ways to define the same API using OpenAPI, and the API can also be defined using other API definition languages.

For a given server implementation / deployment, there would be a specific set of valid enumeration values.

Those elements in https://github.com/opengeospatial/ogcapi-tiles/tree/master/openapi/api are intended to be dynamically returned by the server, or replaced based on the content that they serve.

This is higlighted in the dynamic directory: https://github.com/opengeospatial/ogcapi-tiles/tree/master/openapi/schemas/dynamic directory e.g.:

# This can be implemented as a dynamic enumeration type
# returning all collections available on the server:
$ref: ../../api/all-collections.json

# Standardizing this capability would enable to generate and compile generic clients
# from OpenAPI definitions which are not tied to a particular implementation.

See also the README.md alongside those JSON files.

Please see opengeospatial/ogcapi-common#302 for more details about this approach.

The entire /api set of paths is actually not mandated by the standard

But APIs supporting it would enable the automatic generation of clients from the OpenAPI definition which will work with different implementations / deployment.

but there it might actually not be a bug, since I don't know why one would want anything other than WebMercatorQuad

I hope you're not being serious :) One of the main reason for WMTS / OGC API - Tiles is go beyond WebMercatorQuad. There are several reasons to use tiles not based on a Web Mercator projection. Doesn't Map Libre support 2DTMS other than WebMercatorQuad? Releaseable Basemap Tiles (https://docs.ogc.org/per/24-010.html) was using MapLibre with real Mercator (EPSG:3395) tilesets.

[CommanderStorm]

At least some aspects of the OpenAPI definition [..] should not be taken as normative

I think this explains my confusion in

• Definition of "Core" between spec, website and openapi #175

That only the spec is normative and that URLs are flexible is not really explained in the openapi (what I looked at first) or on https://ogcapi.ogc.org/tiles/

Thanks ❤️

I hope you're not being serious :) One of the main reason for WMTS / OGC API - Tiles is go beyond WebMercatorQuad.

I am, but if there is a good article/discussion/… I can be convinced otherwise.

If you have a globe projection, a regular projection and can animate between the two, this suffices for most usecases…

There are several reasons to use tiles not based on a Web Mercator projection. Doesn't Map Libre support 2DTMS other than WebMercatorQuad? Releaseable Basemap Tiles (https://docs.ogc.org/per/24-010.html) was using MapLibre with real Mercator (EPSG:3395) tilesets.

I have not read that part of the spec and don't know if we can access tiles beyond 85°.
EPSG:3395 is likely close enough to not cause fundamental issues, except maybe at the poles.

For "real projection support" we would first find a sponsor that is prioritising this or volunteer who wants to implement this part. GL-JS is closer as we have the groundwork of globe vs planar, but still some work is left. Native requires more work.
=> If you want different reprojection, you currently need to do this on the server side.

We have a globe and planar projection (with animatability between the two) for WebMercator and for the globe the poles are filled with the edge of the cutoff.

[jerstlouis]

I am, but if there is a good article/discussion/… I can be convinced otherwise.

If you have a globe projection, a regular projection and can animate between the two, this suffices for most usecases…

OGC API - Tiles is also intended for use with 3D globes. And we want to support regions beyond 85 degrees of latitude.
There's Antarctica, the Arctic ocean to map :)

I have not read that part of the spec and don't know if we can access tiles beyond 85°.

EPSG:3395 is not much better for working at the poles since it's still Mercator (just using an oblate spheroid instead of a sphere).

But other 2D Tile Matrix Sets like World CRS84 Quad and the GNOSIS Global Grid work with latitude and longitude directly and support mapping the whole globe. WorldCRS84Quad was also part of the WMTS Simple Profile 1.0 (2013-2016) alongside WebMercatorQuad. There are also several other 2D Tile Matrix Sets defined in the OGC 2DTMS register and illustrated in informative Annexes D and E of the 2DTMS Standard.

It's also possible to define 2D Tile Matrix Sets based on equal-area projections used for axis-aligned global grid hierarchies like ISEA / IVEA ( https://docs.ogc.org/DRAFTS/21-038r1.html#isea9r-dggrs -- opengeospatial/2D-Tile-Matrix-Set#96), HEALPix ( https://docs.ogc.org/DRAFTS/21-038r1.html#HEALPix-dggrs ) and rHEALPix ( https://docs.ogc.org/DRAFTS/21-038r1.html#rHEALPix-dggrs ).

[chris-little]

@CommanderStorm @jerstlouis Tile Matrix Sets are being used with geoZarr in the various cloud infrasstructures, and being used with data as to opposed to plain map pixels. And not just 2D.