Map Layer Blending Problems when Dynamically Switching Layers - Suggestions?

[BrentStevener]

I have customized some code in a custom app of mine to switch between different 'groups' of layers dynamically using one dynamic map service. Through different buttons, it will show only the layers in the legend for that group, as well as hide any layers that are in the service, but which aren't part of that group. The visibility settings of each group are saved as well, so that when you go back and forth between groups, it turns on only the layers you had on for that group previously, and nothing else.

This works perfectly when you have only one layer on at a time and dynamically switch the layers between groups. However, once you add in any additional layers, the image blending gets screwey, and sometimes you see parts of layers hanging on the screen that were already set to invisible, or ones that do not show at all once you set them to visible. Once you change the map extent, it displays fine. The problem all occurs when you enable/disable layers within the same exact extent.

Is there anything I can do to try to fix this problem? Anyone ran into something similar before?

[vipulsoni]

I have customized some code in a custom app of mine to switch between different 'groups' of layers dynamically using one dynamic map service. Through different buttons, it will show only the layers in the legend for that group, as well as hide any layers that are in the service, but which aren't part of that group. The visibility settings of each group are saved as well, so that when you go back and forth between groups, it turns on only the layers you had on for that group previously, and nothing else.

This works perfectly when you have only one layer on at a time and dynamically switch the layers between groups. However, once you add in any additional layers, the image blending gets screwey, and sometimes you see parts of layers hanging on the screen that were already set to invisible, or ones that do not show at all once you set them to visible. Once you change the map extent, it displays fine. The problem all occurs when you enable/disable layers within the same exact extent.

Is there anything I can do to try to fix this problem? Anyone ran into something similar before?

Hi,

Have you tried Refreshing your Dynamic Map ServiceLayer after every layer add or remove operation.

ESRI.ArcGIS.Client.ArcGISDynamicMapServiceLayer dynamicServiceLayer = new ArcGISDynamicMapServiceLayer();

private void ArcGISDynamicMapServiceLayer_Initialized(object sender, EventArgs e)
        {
            dynamicServiceLayer = sender as ESRI.ArcGIS.Client.ArcGISDynamicMapServiceLayer;
        }

dynamicServiceLayer.Refresh();

[BrentStevener]

(I don't think a full quote of my post was necessary... 🙂 )

I have tried refreshing the map layer both when I set layers invisible and visible, and that has no effect. It seems like its something in the map control that still has some sort of cached image or something that shows up sometimes, and I don't know how to 'clear' that out. I have tried disabling client cache for that map layer as well, but it doesn't help.

[BrentStevener]

I think I have found the issue. There were subsequent requests behind the scenes that were being made each time a group switch was made, leading me to a sub where I was setting each layer's visibility settings individually using DynamicServiceLayer.SetLayerVisibility. Each time this happened, a new request was made to retrieve a new image. Being how the requests were made right after each other, sometimes the requests weren't received in the same order from the server, so whatever image request was received last would be the image that displayed.

The fix was to change this to set all layers at once using the VisibleLayers property, which only makes one request once you give it the LayerIDs to show!

[DominiqueBroux · Accepted solution]

You are right, there was a bug when many requests were sent to the server in little time.

This bug is fixed in the next release (3.1)

[BrentStevener]

Updated to 3.1 dlls this morning, and it appears to have fixed the issue! Thanks.