I am having problems cascading WTMS from ArcGIS (v10.5) in GeoServer (v2.13). I can create the store and publish a layer but when I go to Layer Preview I get a screen like the below. The same layer is visible in QGIS, I just cannot seem to get it to cascade in GeoServer.
Looking at the GeoServer log (extract below) ArcGIS seems to be issuing a 400 'bad request' to the tile request.
2018-05-09 16:35:27,922 ERROR [geotools.tile] -
Failed to load image: https://****-****-esr73/arcgis/rest/services/Basemaps/Locate/MapServer/WMTS?request=getTile&tilematrixset=default028mm&TileRow=80&service=WMTS&format=image%2Fpng&style=&TileCol=122&version=1.0.0&layer=Basemaps_Locate&TileMatrix=8&
java.io.IOException: Connection returned code 400
There reference to a very similar issue in another post but the answer is not very specific Adding WMTS basemap.at to GeoServer?
ArcGIS WMTS Capabilities
xmlns:gml="http://www.opengis.net/gml"
xsi:schemaLocation="http://www.opengis.net/wmts/1.0 http://schemas.opengis.net/wmts/1.0/wmtsGetCapabilities_response.xsd"
version="1.0.0">
Basemaps_Locate
OGC WMTS
1.0.0
RESTful
KVP
RESTful
KVP
Basemaps_Locate
Basemaps_Locate
-996015.8687000014 7154565.521499999
-574291.5690000014 7437283.814607762
-8.947362780787937 53.917596728660605
-5.1589489397368204 55.386712748556874
image/jpgpng
default028mm
GoogleMapsCompatible
/>
TileMatrix using 0.28mm
The tile matrix set that has scale values calculated based on the dpi
defined by OGC specification (dpi assumes 0.28mm as the physical distance of a
pixel).
default028mm
urn:ogc:def:crs:EPSG::3857
0
5.590822640285016E8
-2.0037508342787E7 2.0037508342787E7
256
256
1
1
1
2.7954113201425034E8
-2.0037508342787E7 2.0037508342787E7
256
256
1
1
2
1.3977056600712562E8
-2.0037508342787E7 2.0037508342787E7
256
256
2
2
3
6.988528300356235E7
-2.0037508342787E7 2.0037508342787E7
256
256
4
3
4
3.494264150178117E7
-2.0037508342787E7 2.0037508342787E7
256
256
8
6
5
1.7471320750890587E7
-2.0037508342787E7 2.0037508342787E7
256
256
16
11
6
8735660.375445293
-2.0037508342787E7 2.0037508342787E7
256
256
32
21
7
4367830.187722647
-2.0037508342787E7 2.0037508342787E7
256
256
63
42
8
2183915.0938617955
-2.0037508342787E7 2.0037508342787E7
256
256
125
83
9
1091957.5469304253
-2.0037508342787E7 2.0037508342787E7
256
256
249
165
10
545978.7734656851
-2.0037508342787E7 2.0037508342787E7
256
256
498
330
11
272989.38673237007
-2.0037508342787E7 2.0037508342787E7
256
256
995
659
12
136494.69336618503
-2.0037508342787E7 2.0037508342787E7
256
256
1990
1317
13
68247.34668309252
-2.0037508342787E7 2.0037508342787E7
256
256
3979
2634
14
34123.67334154626
-2.0037508342787E7 2.0037508342787E7
256
256
7958
5267
15
17061.836671245605
-2.0037508342787E7 2.0037508342787E7
256
256
15915
10534
16
8530.918335622802
-2.0037508342787E7 2.0037508342787E7
256
256
31829
21068
17
4265.459167338929
-2.0037508342787E7 2.0037508342787E7
256
256
63658
42136
18
2132.729584141936
-2.0037508342787E7 2.0037508342787E7
256
256
127316
84272
19
1066.3647915984968
-2.0037508342787E7 2.0037508342787E7
256
256
254631
168544
GoogleMapsCompatible
the wellknown 'GoogleMapsCompatible' tile matrix set defined by OGC WMTS
specification
GoogleMapsCompatible
urn:ogc:def:crs:EPSG:6.18.3:3857
urn:ogc:def:wkss:OGC:1.0:GoogleMapsCompatible
0
559082264.0287178
-20037508.34278925 20037508.34278925
256
256
1
1
1
279541132.0143589
-20037508.34278925 20037508.34278925
256
256
2
2
2
139770566.0071794
-20037508.34278925 20037508.34278925
256
256
4
4
3
69885283.00358972
-20037508.34278925 20037508.34278925
256
256
8
8
4
34942641.50179486
-20037508.34278925 20037508.34278925
256
256
16
16
5
17471320.75089743
-20037508.34278925 20037508.34278925
256
256
32
32
6
8735660.375448715
-20037508.34278925 20037508.34278925
256
256
64
64
7
4367830.187724357
-20037508.34278925 20037508.34278925
256
256
128
128
8
2183915.093862179
-20037508.34278925 20037508.34278925
256
256
256
256
9
1091957.546931089
-20037508.34278925 20037508.34278925
256
256
512
512
10
545978.7734655447
-20037508.34278925 20037508.34278925
256
256
1024
1024
11
272989.3867327723
-20037508.34278925 20037508.34278925
256
256
2048
2048
12
136494.6933663862
-20037508.34278925 20037508.34278925
256
256
4096
4096
13
68247.34668319309
-20037508.34278925 20037508.34278925
256
256
8192
8192
14
34123.67334159654
-20037508.34278925 20037508.34278925
256
256
16384
16384
15
17061.83667079827
-20037508.34278925 20037508.34278925
256
256
32768
32768
16
8530.918335399136
-20037508.34278925 20037508.34278925
256
256
65536
65536
17
4265.459167699568
-20037508.34278925 20037508.34278925
256
256
131072
131072
18
2132.729583849784
-20037508.34278925 20037508.34278925
256
256
262144
262144
/>
Answer
You were hitting a bug in the underlying GeoTools library where I had made the assumption that not naming the style would use the default, in the same way as a WMS getMap request works. This is how GeoServer interprets the specification too so all my tests passed.
I have now fixed this bug since there is arguably a way to read the WMTS specification to say that there must be a name in the style parameter of a KVP request and that is obviously the way that ESRI's engineers read it. Keep any eye on that PR and when it is merged the next GeoServer master nightly build should pick up the fix and you can test it.
No comments:
Post a Comment