The WmtsLayer class seems not to work with the EPGS:3812 projection coordinate system from an OGC server. Indeed, after the wmtscapabilities.xml http(s) is parsed no tiles are loaded and the TileMatrixSets/Levels aren't requested. The LoadStatus doesn't report any errors. I suspect a problem in the support of the 3812 coordinate system because the wmtscapabilities.xml file mentions 2 layers working with two different projection systems: "topo" (3812) and "overlay" (3857 / WGS84 Pseudo Mercator). The overlay layer works fine.
Is there a way to trace such issue to potentially being able to determine if the projection is well supported or if the problem is rather on the server side?
Map ngiMap = new Map();
Basemap ngiBasemap = ngiMap.Basemap;
LayerCollection layerCollection = ngiBasemap.BaseLayers;
// Define the Uri to the WMTS NGI/IGN service.
Uri wmtsUri = new Uri("https://www.ngi.be/cartoweb/1/1.0.0/WMTSCapabilities.xml");
// Define a new instance of the WMTS service.
WmtsService wmtsService = new WmtsService(wmtsUri);
// Load the WMTS service.
await wmtsService.LoadAsync();
// Get the service information.
WmtsServiceInfo wmtsServiceInfo = wmtsService.ServiceInfo;
// Obtain the read only list of WMTS layer info objects.
IReadOnlyList<WmtsLayerInfo> wmtsLayerInfos = wmtsServiceInfo.LayerInfos;
if (pNgiLayer == ngiLayer.topo)
{
//EPGS:3812 projected coordinate system ETRS/Belgian Lambert 2008
WmtsLayer wmtsLayer3812 =
new WmtsLayer(wmtsLayerInfos[(int)ngiLayer.topo], wmtsLayerInfos[0].TileMatrixSets[1], TileImageFormat.Png8);
layerCollection.Add(wmtsLayer3812);
MyMapView.Map = ngiMap;
MyMapView.SetViewpoint(new Viewpoint(centerMapPoint, 1742380));
}
else
{
//EPGS:3857 projected coordinate system (WGS84 pseudo Mercator)
WmtsLayer wmtsLayer3857 =
new WmtsLayer(wmtsLayerInfos[(int)ngiLayer.overlay], wmtsLayerInfos[1].TileMatrixSets[0],TileImageFormat.Png8);
layerCollection.Add(wmtsLayer3857);
ngiMap.MinScale = 34387;
MyMapView.Map = ngiMap;
MyMapView.SetViewpoint(new Viewpoint(centerMapPoint, 34387));
}
Solved! Go to Solution.
Hello! Which version of Runtime are you using, and on what platform?
I just tested this service with Runtime 100.6.0, I see that both of these WMTS layers have two tile matrix sets available: 3812 and 3857. However, both have problems rendering.
For the "overlay" layer, I see Runtime making network requests with correct parameters (e.g. https://www.ngi.be/cartoweb/1/1.0.0/overlay/default/3812/0/0/0.png) for both tile matrix sets. The server responds with "HTTP/404 Not Found" to all requests, so Runtime has no tiles to draw. I tried to display this layer in a couple other GIS clients and saw the same requests sent, and the same 404 errors returned. So I would call this a server problem — perhaps the tile cache was deleted/corrupted?
For the "topo" layer, Runtime 100.6 does show some unexpected behavior. Although the WMTSLayer loads without error, it continues making repeated GetCapabilities requests instead of loading tiles. We already fixed this bug internally, and the next release of Runtime should be able to draw it normally. I will update this issue when the fix is released. Here's what it looks like on our internal daily build:
Hello! Which version of Runtime are you using, and on what platform?
I just tested this service with Runtime 100.6.0, I see that both of these WMTS layers have two tile matrix sets available: 3812 and 3857. However, both have problems rendering.
For the "overlay" layer, I see Runtime making network requests with correct parameters (e.g. https://www.ngi.be/cartoweb/1/1.0.0/overlay/default/3812/0/0/0.png) for both tile matrix sets. The server responds with "HTTP/404 Not Found" to all requests, so Runtime has no tiles to draw. I tried to display this layer in a couple other GIS clients and saw the same requests sent, and the same 404 errors returned. So I would call this a server problem — perhaps the tile cache was deleted/corrupted?
For the "topo" layer, Runtime 100.6 does show some unexpected behavior. Although the WMTSLayer loads without error, it continues making repeated GetCapabilities requests instead of loading tiles. We already fixed this bug internally, and the next release of Runtime should be able to draw it normally. I will update this issue when the fix is released. Here's what it looks like on our internal daily build:
Hello, Thanks for the answer. The runtime version is well the 100.6 (WPF Windows 10). I'm happy to see that you already fixed the issue. About the overlay rendering on 3812, it seems that it has been intentionally set as not available by keeping the tiles server cache empty. Most probably the overlay is foreseen to be added on the top of a satellite view layer. Do note that, following the test I did, the overlay layer with the matrix set 3857 works (see picture below). It is quite obvious that the Getcapabilities.xml isn't correct. I will report that to the ngi support team.
Do you know when the next release including the fix will be available?
Good news, next release (ArcGIS Runtime 100.7.0) was just released this morning. It contains this WMTS fix and a few other features and fixes. Details: Release notes for 100.7.0—ArcGIS Runtime SDK for .NET | ArcGIS for Developers
I have just tried this latest release and it works fine. Thank you.
Kind regards,
Michel