ThinkGeo.com    |     Documentation    |     Premium Support

Problem upgrading WMTS Layer from 10 to 14

#1

I have a problem with a specific WMTS provider when trying to upgrade from v10 to v14. I am currently at the latest production release. This provider, Planet, requires us to provide an api key and some other data (date range, color visualization) with each image request. In our version 10 application we are overriding OnSendingWebRequest and modifying the RequestUri to add these things. It works perfectly.

On attempting to upgrade to the WmtsAsyncLayer I see that OnSendingWebRequest is gone and in its place is OnSendingHttpRequestMessage. The argument is a little different but buried inside I still find a RequestUri that I can modify as needed. I don’t think that is where our current problem lies.

What appears to be happening is that the RequestUri provided in the argument of OnSendingHttpRequestMessage is not the same as what is provided in the old OnSendingWebRequest. For example, when a request is made for an image in version 10, the AbsoluteUri looks like this:

https://tiles.planet.com/basemaps/v1/latest-series/473b9b21-5940-45c8-9729-c765619eda4d/gmap/10/250/422.png

This is prior to any modifications we make. But when the same request is made with version 14, it looks like this:

https://api.planet.com/basemaps/v1/mosaics/wmts/Latest%20PS%20sen2%20Normalized%20Analytic%20monthly%20subscription/Default/GoogleMapsCompatible15/9/211/124.png

The server does not understand this request and we get the following error:
The HTTP request failed with status code: Not Found

The correct request format is found in the GetCapabilities document, but I don’t think it is being read the same way in version 14 as it was in version 10. With Planet Data you don’t use the base Uri for subsequent requests, only for GetCapabilities.

Maybe you can make some sense out of this without a sample project. The problem is that accessing the Planet data requires a proprietary api key which I cannot easily provide.

Thanks for any help!

Steve

#2

Hi Steve,

It seems the request we sent in v10 is an XYZ request while the one in v14 is a standard WMTS:
/wmts/{Layer}/{Style}/{TileMatrixSet}/{TileMatrix}/{TileRow}/{TileCol}.png

  1. Fix the WMTS request:

The following string in the WMTS Uri seems suspicious,
Latest%20PS%20sen2%20Normalized%20Analytic%20monthly%20subscription

it’s supposed to be the layer name but now it looks like the layer description, can you:

  1. Find out the correct name of the layer you want to display. You can do wmtsLayer.GetServerLayerNames() to get the list of layer names.
  2. Do wmtsLayer.ActiveLayerName = “activeLayerName” to set the active layer name
  3. FYI, you can set ActiveStyleName and TileMatrixSetName as well, which will also be embedded in the wmts request

The request URI should then be something like https://api.planet.com/basemaps/v1/mosaics/wmts/activeLayerName/activeStyleName/tileMatrixSetName/9/211/124.png

Note: We are thinking of renaming the LayerName to LayerId to make it less confusing.

  1. About the legacy XYZ request
  • An wmts layer should not send out an xyz request like …/latest-series/473b9b21-5940-45c8-9729-c765619eda4d/gmap/10/250/422.png, I’m wondering how you get this xyz request template? It’s not from the wmts GetCapabilities, right? Did you customize your wmtslayer in v10 to send this request?
  • If you want to keep using the XYZ service (instead of Wmts), you can create a custom XYZ layer, which’s really straightforward. Here is the source code of OpenStreetMapAsyncLayer, as an example, for your reference. OpenStreetMapAsyncLayer.cs (3.9 KB)

Thanks,
Ben

#3

Hi Ben,

Thanks for the help!

The correct request template is in the GetCapabilities document that goes with this WMTS service. The document clearly identifies this as a WMTS service. We are not generating the request string, only adding the api_key and the color scheme indicator. I have attached the entire GetCapabilities document so you can see what I mean. I believe the version 10 WMTS layer was using this GetCapabilities document differently than the version 14 WMTS layer. Please have a look and see what you think.

Thanks!

Steve

CapabilitiesPanet.zip (3.6 KB)

#4

Hi Steve,

Thanks for the capabilities XML. It looks like the issue was the input layer name. I updated it to the following and it’s now working correctly:

layerOverlay.ActiveLayerName = "Latest PS sen2_normalized_analytic monthly subscription";

If the WMTS layer can’t match the exact layer name, it will build the request URL in its own way, which leads to the behavior you were seeing.

Thanks,
Ben

#5

Ben, it’s working fine now, thanks for the help!

#6

That’s Awesome! :+1: