Handling Missing ows:Constraint in WMTS Capabilities for ArcGIS Runtime .NET

[MaxPower]

Hello Esri Community,

I'm working on integrating a third-party WMTS service in my .NET MAUI application using ArcGIS Runtime SDK for .NET. However, I encountered an issue where the WmtsLayer.LoadAsync() method fails because the capabilities XML from the WMTS service does not include the ows:Constraint element, which seems to be required by the SDK's parser.

private async Task<WmtsLayer> GetWMTSLayer(WMTS wMTS)
{
try
{

WmtsLayer myWmtsLayer = new WmtsLayer(new Uri(wMTS.url), wMTS.layername, wMTS.id);

await myWmtsLayer.LoadAsync();
return myWmtsLayer;
}
catch (Exception ex)
{
await Application.Current.MainPage.DisplayAlert(AppResources.title_error_message, ex.ToString(), AppResources.ok);
}
return null;
}

WMTS Service Details:

• Service URL: https://owsproxy.lgl-bw.de/owsproxy/ows/WMTS_LGL-BW_ATKIS_DOP_20_C?service=WMTS&request=GetCapabilit...
• Layer ID: DOP_20_C
• TileMatrixSet ID: GoogleMapsCompatible

Issue:

When attempting to load the WMTS layer using the provided URL, layer ID, and tile matrix set ID, I receive an error indicating that the parser could not move to ows:Constraints in the capabilities XML.

Additional Information:

According to the OGC WMTS standard, the ows:Constraint element is not mandatory for a valid WMTS capabilities document. However, it appears that the ArcGIS Runtime SDK for .NET expects this element to be present, which causes the loading process to fail when it is missing.

Request for Help:

I am looking for guidance on the following:

1. How can I handle the missing ows:Constraint element in the capabilities XML to successfully load the WMTS layer using the ArcGIS Runtime SDK for .NET?
2. Is there a way to programmatically add the required ows:Constraint element to the capabilities XML before creating the WmtsLayer?
3. Are there any best practices or recommended approaches to resolve this issue without modifying the third-party WMTS service?

Thank you for your assistance!

Best regards

[dotMorten_esri]

This error is thrown if the ows:Constraint is missing and looks like an issue with your service, and needs to be addressed server-side. According to the spec this is a required parameter:

---

All WMTS servers operating in a procedure oriented architecture style and using HTTP SHALL specify with an ows:Constraint parameter the encodings that MAY be sent using HTTP GET or HTTP POST.

 WMTS spec: https://www.ogc.org/standard/wmts/

[MaxPower]

Thank you for your response. Unfortunately, I don't have any access to the WMTS service because it is provided by a third party. This limits my ability to make any server-side modifications to include the ows:Constraint parameter. I am considering writing an email to the provider of the WMTS to request that they include the ows:Constraint parameter as specified in the WMTS standard.

[MatveiStefarov · Accepted solution]

Runtime needs ows:Constraint to determine which message-encoding to use for the service (KVP or RESTful).  Looks like this service is powered by a very old version of OpenLayers, which used to omit this required piece of metadata from its capabilities.  The bug was fixed in OpenLayers v4.6.0 (2017): https://github.com/openlayers/openlayers/issues/6835

If you have any control or influence over this service, I recommend upgrading the server software!

The simplest workaround would be to download this server's capabilities document, edit it to be standards-compliant, and re-host the XML file yourself.  The capabilities document specifies absolute URLs for loading tiles, so it doesn't matter to Runtime where it was loaded from.  I edited the file and hosted it on the local network as a proof of concept -- it worked!

And here is the edited OperationsMetadata section that I used:

<ows:OperationsMetadata>
    <ows:Operation name="GetCapabilities">
        <ows:DCP>
            <ows:HTTP>
                <ows:Get xlink:href="https://owsproxy.lgl-bw.de/owsproxy/ows/WMTS_LGL-BW_ATKIS_DOP_20_C?">
                  <ows:Constraint name="GetEncoding">
                    <ows:AllowedValues>
                      <ows:Value>KVP</ows:Value>
                    </ows:AllowedValues>
                  </ows:Constraint>
                </ows:Get>
            </ows:HTTP>
        </ows:DCP>
    </ows:Operation>
    <ows:Operation name="GetTile">
        <ows:DCP>
            <ows:HTTP>
                <ows:Get xlink:href="https://owsproxy.lgl-bw.de/owsproxy/ows/WMTS_LGL-BW_ATKIS_DOP_20_C?">
                  <ows:Constraint name="GetEncoding">
                    <ows:AllowedValues>
                      <ows:Value>KVP</ows:Value>
                    </ows:AllowedValues>
                  </ows:Constraint>
                </ows:Get>
            </ows:HTTP>
        </ows:DCP>
    </ows:Operation>
</ows:OperationsMetadata>

This isn't really a general-purpose workaround, since you would have to re-edit and re-host the capabilities document any time the original service is updated.  But seeing that they are still running 7+ year old version of OpenLayers, I'm guessing they don't update very often.

[MaxPower]

Thank you for the detailed explanation and workaround.

Unfortunately, I do not have any control or influence over this WMTS service, as it is provided by a third party. Upgrading the server software or making server-side changes is not an option for me.

Given this constraint, I am exploring client-side solutions to handle the missing ows:Constraint and successfully load the WMTS layer using the ArcGIS Runtime SDK for .NET. As you suggested, a possible workaround could involve downloading the capabilities document, editing it to be standards-compliant, and re-hosting the XML file myself.

I understand that this approach requires re-editing and re-hosting the capabilities document whenever the original service is updated, which might be manageable given that they are running a very old version of OpenLayers.

I am also considering writing an email to the provider of the WMTS to request that they include the ows:Constraint parameter as specified in the WMTS standard.

Thank you again for your assistance and the proof of concept.

[MatveiStefarov]

Good news!  ArcGIS Maps SDK version 200.5.0 was just released today.  We added heuristics to guess the missing "encoding" constraint, so this service can now be opened without any workarounds.

Thank you for bringing this one to our attention!

[MaxPower]

Thank you for the update! I appreciate the new features in ArcGIS Maps SDK version 200.5.0.

I had already informed the host of the WMTS about the issue, and they have updated the capabilities to include the necessary ows:Constraint elements. It's great to hear that the SDK now has heuristics to handle this as well, so the service can be accessed without workarounds.

Thanks again for your support!