ThinkGeo.com    |     Documentation    |     Premium Support

MapSuite 7.0 WMTSOverlay/WMTSLayer

Hi,



I would like to use MapSuite 7.0 WMTSLayer new functionality in our application.



So far, I’ve based myself on the sample provided here:



wiki.thinkgeo.com/wiki/Map_S…TS_Overlay



I tested the example exactly as provided, using MapSuite release build 7.0.0.0 as well as the development 7.0.4.0 version, but I’ve ran into various problems:



-   I get a format exception “Input string was not in a correct format.” when my computer Windows localization is set to French (France).

   at System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt)
   at ThinkGeo.MapSuite.WpfDesktopEdition.WmtsTiledOverlay.DBg=(XmlNode DRg=, XmlNamespaceManager Dhg=)
   at ThinkGeo.MapSuite.WpfDesktopEdition.WmtsTiledOverlay.CRg=(XmlElement Chg=, XmlNamespaceManager Cxg=)
   at ThinkGeo.MapSuite.WpfDesktopEdition.WmtsTiledOverlay.InitializeConnection()

This works fine if I set my localization to English (US).



-  Once I get around the above problem, no exception is thrown but the map in the example is blank.

I traced the http requests coming from the application (no exception is drawn even when I set the overlay’s DrawingExceptionMode to Draw).

server.caris.com/spatialfusionserver/services/ows/wmts/NaturalEarth/1.0.0/WMTSCapabilities.xml 

server.caris.com/spatialfusionserver/services/ows/wmts/NaturalEarth/1.0.0/newworld/default/GoogleMapsCompatible/3/200/197.png

server.caris.com/spatialfusionserver/services/ows/wmts/NaturalEarth/1.0.0/newworld/default/GoogleMapsCompatible/3/199/199.png

[…]



The two last requests are wrong, as they try to request for tiles (197,200) and (199,199) for zoom level 3 while the TileMatrix at this level is of size 8x8, as we can tell from the GetCapabilities response: 






<TileMatrixSet>
            <ows:Identifier>GoogleMapsCompatible<ows:Identifier>
             
            <TileMatrix>
                <ows:Identifier>3<ows:Identifier>
                <ScaleDenominator>6.988528300358972E7<ScaleDenominator>
                <TopLeftCorner>-2.0037508342789244E7 -2.0037508342789244E7<TopLeftCorner>
                <TileWidth>256<TileWidth>
                <TileHeight>256<TileHeight>
                <MatrixWidth>8<MatrixWidth>
                <MatrixHeight>8<MatrixHeight>
            <TileMatrix>
 
<TileMatrixSet>



- The KVP server encoding type example did not work either but it only performed the GetCapabilities request:

v2.suite.opengeo.org/geoserver/gwc/service/wmts/?Service=WMTS&Request=GetCapabilities



- I’ve tested WMTSLayer as well, by putting the WMTSLayer over a LayerOverlay, and by basing myself off this example:

<a href=“wiki.thinkgeo.com/wiki/Map_Suite_Wpf_Desktop_Edition_Layers_%26_FeatureSources_Samples#WMTS_Layer” tabindex=“0” style=“color: #000000;”>wiki.thinkgeo.com/wiki/Map_S...WMTS_Layer</a>

but I’ve had not much success. Not only were the TileRow/TileCol out of bounds, but also when using KVP encoding, the request had wrong arguments, and looked pretty much like this:

[…]Service=WMTS&VERSION=1.0.0&Request=GetTile&Style=normal&TileMatrixSet=TestSet&TileMatrix=TestSet:8&TileRow=62345&TileCol=62565

As you can see, we have TileMatrix=TestSet:8, when it should be TileMatrix=8 (it appends the TileMatrixSet for some reason).





Thanks.





Hi David, 
  
 Thanks for your detailed information, it turns out to be a bug and has been fixed, would you please get the latest version 7.0.8.0 or 7.0.0.8 and try it again? 
  
 Hope it helps 
  
 Summer

Hello Summer, 



I tested WMTSOverlay and WMTSLayer on 7.0.8.0, and they both worked with the servers and configuration provided in the examples. 

However, the localization issue due a different regional formatting still occurs. 



More importantly, I tested them with our own set of map servers and I ran into some more issues. As before, WMTSLayer requests non existing tiles, that is, where tile row and column are above tile matrix limits.

After close inspection, it appears that the extent provided by the ows:BoundingBox field in the TileMatrixSet definition of the WMTS GetCapabilities request is not at all taken into account by WMTSLayer, and calculations over tile’s rows/columns are done by default over the world extent. I confirmed this behaviour since I noticed that after setting the extent of the layer grid to be over the world extent, MapSuite could display it. But this is not a solution. 



On a side-note, we have problems through our customer portal. It appears that the daily development/production builds links are switch over the day between the 6.0 and 7.0 MapSuite branches, sometimes not letting us download the latest 7.0 build.  Do you know what this could  be due to?



Thanks.

Hi David, 
  
 Thanks for your further inforamtion, according to the xml got from server.caris.com/spatialfusionserver/services/ows/wmts/NaturalEarth/1.0.0/WMTSCapabilities.xml the ows:WGS84BoundingBox is under Layer node rather TileMatrixSet Node, and the WMTSOverlay will parse the boundingbox under layer node, would you please give "ows:BoundingBox field in the TileMatrixSet definition" a double check? 
  
 About the second question, it is because we freezed the code to make some amendment for 7.0, but now the daily buid has recovered. 
  
 Waiting for your further information 
  
 Summer

Hi Summer,



I checked our server’s responses and there seems to be a wgs84bounding under Layer if and only if the layer’s grid’s supported crs is equal to wgs84.

The problematic layers support epsg:3857, and in this case, the boundingbox (for this particular CRS) is being defined in the TileMatrixSet only.



I’ve checked the standard at OGC, and the bounding box is not required to be in the Layer’s definition, it can be in the TileMatrixSet definition as well.



Regardless, in the OGC’s specification, the topLeftCorner within the TileMatrix definitions seem to be only like the only standard way to refer to the “starting point” of the tile matrix, as they are the only “bounding-box related” mandatory field, and as far as I understand, the extent’s bounding box should not be used for calculating the tile row’s and column’s.



About the customer portal, everything seems to be working now.



Thanks,



David

Hi David,  



Thanks for your reminding, we need to double check the parsing code, anything new will be updated immediately. Meanwhile, would you please provide us your capabilities reply xml for a further test.



Sorry for the inconvenience. 



Summer.

Hi Summer,



Here is the GetCapabilities response.



Thanks.

wmtsCapabilities.xml (15.7 KB)

Hi David, 
  
 Thanks for your xml, and we are debuging it now, anything new will be posted here immediately 
  
 Best Regards 
  
 Summer

Hi David, 
  
 We have made some amendment to the WMTSTileOverlay, would you please get the latest version 7.0.24.0 and try it again. If the problem is still, if possible, would you please provide us a uri to access the images in your server, this will be highly appreciated for debug. 
  
 Best Regards 
  
 Summer 


Hello Summer, 
  
 7.0.24.0 did not fix my problem. Unfortunately, I was unable to provide an URI since our WMTS servers are not in a public server, and it was hard for me at the time to open a tunnel so that you could test them. 
  
 For the reference, the WMTS servers we are testing are GeoWebCache/MapCache(MapServer) implementations. 
  
 Regardless, last time I retested the latest WMTSLayer from prod versions 7.0.0.40+, not even the sample from your wiki was working. What has been the status of this issue over the different versions? 
  
 Regards, 
  
 David

Hi David, 
  
 Thanks for reporting this. 
  
 About "7.0.0.40+" now it is fixed, would you please try the get the latest version 7.0.0.45 and try it again. 
  
 About "7.0.24.0 did not fix my problem" , we are investigating it, any thing new will be updated here. 
  
 Best Regards 
  
 Summer

Hi David, 
  
 We made some change in WMTS, would you please try it? 
  
 if you have any more question , please feel free to let us know. 
  
 Best Regards 
  
 Summer