mmcfarland
commented
7 years ago An attempt to concisely show the different behavior in the 4.2 API with different URLs.
TNC URL Behavior link
- With one
[{ id: 1}]element in thesublayersproperty, the URL parameter used islayersand it loads correctly. - With more than one
[{ id: 1}, {id: 2}]element in thesublayersproperty, the URL parameter used isdynamicLayersand this fails because that property is not enabled.
ESRI URL Behavior link
- With one
[{ id: 1}]element in thesublayerslist, the URL parameter used islayersand it loads correctly. - With more than one
[{ id: 1}, {id: 2}]element in thesublayerslist, the URL parameter used islayersand it loads correctly.
The behavior with the 3.x version of the JSAPI is to use the layers URL parameter which is the same as 4.2 with ESRI URL but not the TNC URL. However, the desired URL can be constructed manually, and will produce the correct composited image output - just not using the JS API.
Manually constructed non-dynamicLayer service (results in correct composite png)
salient URL parameters:
&bboxSR=102100
&imageSR=102100
&size=471%2C355
&dpi=96
&format=png32
&transparent=true
&f=image
&layers=show:1,2This is most clearly showed by this stripped down JS Bin: https://jsbin.com/letapemidu/1/edit?html,output.
To see the difference, replace the url argument to the esriMap between esriUrl and tncUrl and inspect the network tab image requests, you will see that only the tncUrl will cause the JSAPI to issue the request with the dynamicLayers URL parameter. If you remove one layer so that the sublayers argument has only one element, both will behave the same way, using the layers parameter.
Notes:
- I have the TNC service proxied through ngrok to serve it over HTTPS, to allow JS Bin to work. If that proxy terminates, I'll have to regenerate the URL
- We don't control the AGS services this is intended to consume, so it's difficult to alter things such as TLS, service hierarchy and
dynamicLayersproperty.
Desired behavior
Have the API consistently use the layers=show:1,2 format, which it seems the library can produce, just not on this particular URL.
This issue builds on the work in https://github.com/CoastalResilienceNetwork/regional-planning/pull/78.
I used this ESRI example as a reference for implementing support for sublayers: https://developers.arcgis.com/javascript/latest/sample-code/sandbox/index.html?sample=layers-mapimagelayer-sublayers.
Initially, I was only able to turn on one layer at a time. Turning on additional layers generates a request that fails.
When activating a single layer, the
layerquery parameter in the request that fetches the layers looks like this:layers: show:1(1 being the layer id).However, when I turned on a second layer, the query parameter changes to this:
Which results in this message:
Turning on dynamic layers on the map service allows the request to succeed. However, there is nothing dynamic about the layers. We are not requesting a different renderer or symbology. We are only specifying an id and whether or not the layer is visible.
Using the ESRI demo mentioned above as an example, toggling those layers on and off results in a
layerquery param that looks likelayers: show:1orlayers: show:1,3, unless you turn on the railroads layer (which has custom symbology, and requires dynamic parameters in the request).I modified the ESRI demo to use a TNC service that doesn't support dynamic layers. You can view it here: http://jsbin.com/fuzilafuke/1/edit?html,output (You have to view it in Firefox because of the TNC service doesn't support HTTPS, and turning off HTTPS on JSBin breaks it in Chrome).
The layer query param turns into the more verbose version for dynamic layers when multiple layers are turned on, even though those layers have no dynamic settings. This makes me thing that there additional differences between the settings of the TNC server and ESRI server. We also may be using the wrong layer class.