raise warning/error or use WKT for WMTS boundingbox CRS when no URI exists

[AndrewAnnex]

So an issue I've known would be coming my way is in the use of CRS_to_uri inside the WMTSCapabilities.xml endpoints for the bounds object CRS parameter, which when using a slightly tweaked/custom CRS can result in a None being specified in the WMTS XML document. This causes issues with clients like QGIS, but will work as soon as a valid CRS URI (or interestingly WKT) is swapped in.

After looking at this, I think I must conclude that this isn't a bug in pyproj/rasterio/rio-tiler. It is totally possible to define a tilematrixset or COG that uses a CRS that may use a geographic CRS that won't resolve with to_authority despite only minor modifications.

Lowering the confidence parameter used in rio-tiler could help in some cases but won't work universally and could cause some other unintended issues. So it made the most sense to open an issue here and discuss solutions.

I think then there are 2/3 options

1. raise an error when CRS_to_uri evals to None
2. raise a warning in the logs when this occurs and continue to allow None to pass through
3. Fall back to the WKT

After reviewing OGC 06-121r9 (sections 10.2-10.3) it does look like for the most part clients would be expecting this CRS parameter to be a URI/URN. However, while testing I was able to use the full WKT string for the crs parameter and QGIS/GDAL was able to use it correctly. Given the ubiquity of GDAL, my expectation would be that this could be seen as a sensible fall back even if it's technically out-of-spec with the OGC, although maybe this is just plainly a bad idea...

My suspicion then is that option 1 would also be too aggressive of a fix and that it might just be best to keep the change in behavior minimal by logging a warning.

I am happy to implement this, but wanted to check with others before starting to see if there are other ideas or ways to work with the WMTS spec in ways I hadn't considered

[vincentsarago]

After reviewing OGC 06-121r9 (sections 10.2-10.3) it does look like for the most part clients would be expecting this CRS parameter to be a URI/URN. However, while testing I was able to use the full WKT string for the crs parameter and QGIS/GDAL was able to use it correctly. Given the ubiquity of GDAL, my expectation would be that this could be seen as a sensible fall back even if it's technically out-of-spec with the OGC, although maybe this is just plainly a bad idea...

Considering WMTS is a >10 yr old spec and not really up to date I would say: Let's do what ever we think is good for the users :-)

I'm fine having WMTS response that are not 💯 following the specs especially if it's for specific uses case like yours where you know what you are doing ;-)

[vincentsarago]

FYI: in the new OGC Tiles /tiles and /tiles/{tileMatrixSetId} endpoints we use CRS_to_uri

titiler/src/titiler/core/titiler/core/factory.py

Line 568 in 22e48f0

"crs": CRS_to_uri(crs or WGS84_CRS),

for the bounding box. The OGC tiles specs allows the CRS to be either a URI or a wkt https://schemas.opengis.net/tms/2.0/json/crs.json

[AndrewAnnex]

okay excellent, I will work on this and double check things with qgis (rasterio can also probably use the wmts.xml files also to make sure everything is working).

[AndrewAnnex]

by the way @vincentsarago, have you reconsidered #546 ? The reason for me using wmts is to quickly demonstrate mosaic.json capabilities to users more familiar with QGIS. Now that QGIS has support via the OGCAPI gdal driver for OGC tiles it would make it even easier.

[vincentsarago]

by the way @vincentsarago, have you reconsidered #546

What reconsideration? I've just added tilesets endpoint and we already had tilematrixset endpoints. I'm not sure what we can do more

[AndrewAnnex]

hmm okay I thought the last comment on that issue was indicating a won't fix.

But in my testing I also wasn't able to use QGIS or the GDAL OGCAPI successfully, either way I got an error relating to a missing "bbox" parameter. Looking at GDAL's source there is a lookup for that key in the "coverage" section of the driver, but I didn't investigate further and I haven't really read into the coverages aspect of ogcapi yet. In QGIS I did select to use TILES in the api field also with no success.

Do you have a working example with gdalinfo OGCAPI:https://titiler.xyz/... handy?

[vincentsarago]

We can't fully support the OGC Tiles API, I'm not sure what QGIS/GDAL expect to be honest!

[AndrewAnnex]

okay well I may have misinterpreted that comment regarding what the OGC Tiles endpoints are for then. In anycase to solve the question for this issue something like ((CRS_to_uri(crs) or crs.to_wkt()) or WGS84_CRS) could work

[vincentsarago]

@AndrewAnnex do we have anything to do here?

[AndrewAnnex]

okay yes there would need to be a PR to implement the options I suggested in the first posting or the most recent idea for ((CRS_to_uri(crs) or crs.to_wkt()) or WGS84_CRS), I was waiting for #1052 to get merged before implementing, but I am about to go on vacation for a week and a bit and probably won't get to this until the new year.