Select to view content in your preferred language

VisibleLayers, ArcGISDynamicMapServiceLayer and REST n! requests

672
2
09-02-2010 04:59 AM
JakubGutkowski
Emerging Contributor
If you use ArcGISDynamicMapServiceLayer, REST and browser request caching, VisibleLayers can cause n! (factorial) requests to MapServer.

Order of layers in REST Map Server is defined in MDX file, therefore asking for {1,2} or {2,1} it's always translated to the order defined in MDX.

Example
If we have for instance two layers that we want to show by ArcGISDynamicMapServiceLayer by setting VisibleLayers. Let�??s assume that our layers ID are as follow: 1 and 2.


  1. If we will set VisibleLayers in code to {1,2}, request to REST is generated and Image is returned �?? that�??s fine.

  2. Now if we will set VisibleLayers to empty {} so no Images will be show, REST request is not generated and base map is showed without any images on it �?? that�??s fine.

  3. If we will then set VisibleLayers in code to {1,2}, REST request is not generated and Image is returned from cache.

  4. If we will then set VisibleLayers in code to {2,1}, request to REST is generated and Image is returned �?? that�??s fine, I understand why this generates the request I could think of few places where we can take advantage of that if map servers allows it;

  5. Now if we will set VisibleLayers to empty {} so no Images will be show, REST request is not generated and base map is showed without any images on it �?? that�??s fine.

  6. If we will then set VisibleLayers in code to {2,1}, REST request is not generated and Image is returned from cache.


This would be a proper behaviour if sort order of VisibleLayers would implicated that image returned by {1,2} is different than image returned by {2,1}. But it�??s not, is the same image. Map Server is sorting layers ID based on MDX file on the server, so our request {2,1} is transformed into {1,2} (or vice versa), but still request is generated, and we will download the Image to client.

Solution
IMO if this is a known limitation, this should be provided in SDK documentation, and/or GetImageUrl method in MapService should do sorting for us.


internal void GetImageUrl(Envelope extent, int width, int height, int[] layers, string imageFormat, bool disableClientCaching, bool useMime, ObservableCollection<LayerDefinition> layerDefinitions, TimeExtent timeInterval, UrlCompleteHandler onComplete);

Declaring Type: ESRI.ArcGIS.Client.Services.MapService
Assembly: ESRI.ArcGIS.Client, Version=2.0.0.314


it can be achieved by just replacing this code:

builder.Append("&layers=show:");
for (int i = 0; i < layers.Length; i++)
{
        if (i > 0)
        {
                builder.Append(",");
        }
        builder.AppendFormat("{0}", new object[] { layers });
}


with this (second line):

builder.Append("&layers=show:");
Array.Sort(layers);
for (int i = 0; i < layers.Length; i++)
{
        if (i > 0)
        {
                builder.Append(",");
        }
        builder.AppendFormat("{0}", new object[] { layers });
}


Workaround
If we don�??t want to have this additional and unnecessary request to REST we just need to sort Array before assigning it to VisibleLayers. But this little tweak, instead of n! (if we are working on the set, n is number of elements in set, ! - factorial) requests to map server for images we will always have one.

Even if we are not working on the set, so each time we select a layer we add it to VisibleLayers, it�??s still better to sort it.
0 Kudos
2 Replies
DominiqueBroux
Esri Frequent Contributor
Except if you generate by code the n! combinations without changing the map extent, I don't see any use case where this is an issue.
The VisibleLayers is most generally a constant except when a visible layer is added or removed but in this case a new request is needed.

Note that in the worst case, the sort could be made by the application.
0 Kudos
JakubGutkowski
Emerging Contributor
The VisibleLayers is most generally a constant except when a visible layer is added or removed but in this case a new request is needed.


Request is needed if the response is not cached. In situation 1,2 and 2,1 request is not needed or you specify that you do not want to cache response, than request is needed.

Note that in the worst case, the sort could be made by the application.


Yup, and how dev should know about this? Or why than there is option to "do not cache" responses?

IMO some constancy is needed, if you allow responses to be cached by browser, therefore sort should be done on control side if not documentation should have in bold that this can cause unnecessary requests. Do not depend on dev that he will figure it out that cache is working only when he will always provide VisibleLayers in the same order.
0 Kudos