WMTS support

[nickeopti]

Experimental support for WMTS, including the Dimension tag. This is at the moment pretty much a working proof-of-concept, initially made just to test the feasibility. A lot of polishing is required before it may become ready to merge.

But first, is this a feature we want to add? It is suprisingly simple, and doesn't add much complexity, as it primarily relies on existing functionality. It essentially just provides an endpoint for fetching GetCapabilities -- the rest is handled as usual.

As far as I can tell the implementation adheres to the WMTS standard. I've cross-checked with Titiler as a reference point, and the processes seem comparable (apart from their implementation being much more generalised). The implementation is tested in QGIS on small test rasters.

Remaining tasks and questions (if we want to add it):

1. Support usage of all the normal endpoints for rasters; /rgb, /compute(?), as well as /singleband, along with all their options. This is currently hardcoded to /singleband without any options.
2. Dynamically add zoom levels instead of hardcoding them in the wmts.xml template file? If doing so, data is available here http://schemas.opengis.net/tms/1.0/json/examples/.
3. Are there any restrictions on zoom levels? I see Titiler deduce zoom level restrictions from data, somehow. Does Terracotta have such limits?
4. Is it correctly understood that WorldWebMercatorQuad is the correct reference system?
5. I've used xml.etree.ElementTree to build the capabilities XML file. It seems like the proper way for me, but I'm not satisfied with the code. I think it is too convoluted, and frankly hard to read. I'm actually leaning towards inserting elements as strings in the template instead. Thoughts on this?
6. Where shall static template/data files be stored? Regarding the wmts.xml and possibly WebMercatorQuad.json file(s).
7. Currently the dimension option blindly trusts the user that the supplied key makes sense as a dimension (ie that the raster files have the same bounds). Shall we verify this?
8. Documentation.
9. Testing. No efforts have been made here yet.

[j08lue]

But first, is this a feature we want to add? It is suprisingly simple, and doesn't add much complexity, as it primarily relies on existing functionality. It essentially just provides an endpoint for fetching GetCapabilities -- the rest is handled as usual.

I think WMTS support is generally a relevant feature to add, since it may make usage of Terracotta more plug-and-play with various GIS software. Since it is basically just about adding GetCapabilities, we do not increase the complexity of the current features, only adding a little feature.

The WMTS feature, however, comes with a commitment: The standard for the XML document is rather heavy, compared to the nice simplicity of the map tiles API. We will have to maintain it in the future to be sure that its behavior is consistent with the other endpoints.

I would recommend that we add the WMTS support, try it for a while, and then can still cut it out again, if we notice that we have a hard time maintaining it.

Is your project still up for using Terracotta-powered WMTS, @panakouris and @PaulDanielML, or did they have to have WMS?

[panakouris]

They went with the WMS solution

[dionhaefner]

I'm up for merging this if we can get this tested well and keep the complexity low.

Support usage of all the normal endpoints for rasters; /rgb, /compute(?), as well as /singleband, along with all their options. This is currently hardcoded to /singleband without any options.

How does passing options to WMTS work?

Dynamically add zoom levels instead of hardcoding them in the wmts.xml template file? If doing so, data is available here http://schemas.opengis.net/tms/1.0/json/examples/.

What do you mean by dynamically? Zoom levels are fixed in WMTS, right? So having them in the template is fine with me.

Are there any restrictions on zoom levels? I see Titiler deduce zoom level restrictions from data, somehow. Does Terracotta have such limits?

No, Terracotta has unlimited zoom (you just oversample the raster at some point).

Is it correctly understood that WorldWebMercatorQuad is the correct reference system?

Yes that should be correct.

I've used xml.etree.ElementTree to build the capabilities XML file. It seems like the proper way for me, but I'm not satisfied with the code. I think it is too convoluted, and frankly hard to read. I'm actually leaning towards inserting elements as strings in the template instead. Thoughts on this?

Yes, you should not need an XML parser to inject these values into the template. Frankly I would just use string.Template or so.

Where shall static template/data files be stored? Regarding the wmts.xml and possibly WebMercatorQuad.json file(s).

Wherever it makes sense, just register them in package_data in setup.py and they get installed along with the rest of Terracotta. See how the colormaps are handled for example.

Currently the dimension option blindly trusts the user that the supplied key makes sense as a dimension (ie that the raster files have the same bounds). Shall we verify this?

Yes, that should be verified. Can you run us through what a dimension is in WMTS?