Add missing supported_crs to mosaicjson wmts endpoint #995
Conversation
also made the bounds_crs discovered from the tms's geographic crs currently I call '.srs' on the geographic crs to get the bounds crs but it may make sense to add a function to determine the more compact urn representation first, failing that allow the WKT representation to pass through.
| @@ -37,7 +37,7 @@ | |||
| <ows:Title>{{ title }}</ows:Title> | |||
| <ows:Identifier>{{ layer_name }}</ows:Identifier> | |||
| <ows:Abstract>{{ title }}</ows:Abstract> | |||
| <ows:WGS84BoundingBox crs="urn:ogc:def:crs:OGC:2:84"> | |||
| <ows:WGS84BoundingBox crs={{ bounds_crs }}> | |||
There was a problem hiding this comment.
would be weird to have WGS84BoundingBox not being in WGS84
There was a problem hiding this comment.
it is but I think this is just an artifact of the the WMTS spec, GDAL (via gdalinfo/qgis) seemed happy to work with a mars urn here in the crs. Unless its possible to call it a BoundingBox sans geoid name? I'll have to dig more into the wmts spec to see if there is a different choice to make.
There was a problem hiding this comment.
ahh looks like OGC 06-121r3 does mention an alternative BoundingBox that is more extendable (can be n dimensional for example). Now I can either update to only use BoundingBox or use WGS84BoundingBox if the bounds_crs is 4326. thoughts?
There was a problem hiding this comment.
okay went with the 2nd option, so now BoundingBox is only used if the geographic_crs is not WGS84/4326. I tried to add a test that is failing in a unexpected way, maybe something to do with the mock interface or how rasterio works but I'd expect the endpoints to always return a uri and not a urn
… I don't understand
…read methods when a tms is specified
|
@vincentsarago, I noticed that when trying to make a WMTS from a single cog that the geographic_crs bounds were getting set to the whole globe, so grabbing the geographic_crs from the TMS I think makes sense to do here without needing to update rio_tiler, so I updated the pr to be more explicit about that. I think however that the coord_crs may need to be added as a query parameter to |
I feel I should remove the geographic bounds and info about min/max zoom in |
|
@vincentsarago I don't see that as correct, we have ARD COGs that are using non earth CRSs, and these endpoints are still valid and useful without the TMS. Removing them from rio-tiler is also premature unless I am misunderstanding something |
|
@AndrewAnnex the issue is that having tms related information in same for the I'm going to push a PR in rio-tiler explaining the changes. |
|
done in #1004 |
also made the bounds_crs discovered from the tms's geographic crs. This enables non-earth TMSs to work with GDAL/QGIS
currently I call '.srs' on the geographic crs to get the bounds crs but it may make sense to add a function to determine the more compact urn representation first, failing that allow the WKT representation to pass through.
I was able to sort of test this by manually editing the WMTS response until it worked with QGIS but let me think about the srs question above a bit more before merging. As far as I could tell, QGIS and GDAL had no issue parsing a WKT2 crs string for the supported_crs but I am not exactly sure if that is true also for the bounding box crs.
It will be difficult to test with non earth TMSs within this repository as the ones I am developing are not official with the naming authority so this may take a few tries. At least it shouldn't break any existing functionality or tests..