Changing Renderer on Sublayer in ArcGISDynamicMapServiceLayer

[GeoffreyGauchet]

Here's my situation:

I'm using a DynamicMapServiceLayer to populate a Legend/TOC widget. Everything loads fine, with groupings and sublayers and legends showing up fine. Now, all of the layers in a specific group are of the GeometryType esriGeometryPolygon. This works fine when viewing a single layer, however, displaying a second layer on top of that layer covers up the first layer, making the map not very useful.

For instance, this is our Layout:

Indicators

• Layer A


• Layer B


• Layer C


• Layer D


• Layer E

What we'd like to do is have the first layer that's checked in the TOC be a Polygon, then the second layer (if one gets checked) that is displayed on top to be displayed as say, Circle markers of various sizes.

So, for instance, if a user checks Layer B to be displayed, it's a Polygon. Then, if they check the box next to Layer D, instead of it rendering as a Polygon, it renders as Circles of various sizes, to allow the user to compare the data.

But if the user just checks Layer D by itself, it gets rendered as a Polygon.

Is there any way to accomplish this? I can access the individual layers just fine and I can handle capturing the event of which layer has been Checked in the TOC. The issue comes down to changing the rendering of the layer.

This is how we'd like the final outcome to look like (I used two different layers to display the example here)
[ATTACH=CONFIG]16135[/ATTACH]

[DominiqueBroux]

From API version 3.0 and server 10.1, you can change the symbology dynamically (if the functionality has been enabled at the server side).

There is a sample here : http://resources.arcgis.com/en/help/silverlight-api/samples/start.htm#DynamicLayer

Using that, you might change by code the symbology depending on the layers that are turned on (though will need some development)

[GeoffreyGauchet]

Thanks... I've looked at that previously, but the issue lies in that each layer doesn't have the same units or class breaks. That example looks like it requires you to set up the class breaks in the code, which won't work here. Some layers are integers, some are percentages, some are decimals, etc. And having the same units doesn't necessarily mean that the class breaks are the same.

So, for instance, Layer A may show the Asian Population for a neighborhood, which would be an percentage. Layer B might show Average Income for residents in neighborhood, which would be dollar amounts. I'd like to allow users to enable the Asian Population layer (which would be polygons) and then enable the Average Income on top of that, and it would show the circle symbols on top.

Looking at that example, it looks like I'd have to handle the class breaks depending on each layer, which I can't really hardcode.

[DominiqueBroux]

You can use ArcGISDynamicMapServiceLayer.CreateDynamicLayerInfosFromLayerInfos in order to get the renderers defined at the server side.
Using that as starting point will avoid you to create class breaks renderer by code.

[GeoffreyGauchet]

Still not having any luck with this. I used the CreateDynamicLayerInfosFromLayerInfos method to get a DynamicLayerInfoCollection. This is the result of that:

[ATTACH=CONFIG]16344[/ATTACH]

As you can see, there's nothing about the renderer returned. Am I missing something?

Here's the Drawing Info for this layer on the server:

[ATTACH=CONFIG]16345[/ATTACH]

[GeoffreyGauchet]

For what it's worth, every example code I use just renders the layer exactly like the original, even when duplicating the layer, for example, the code here just dupes the entire map service and renders exactly the same

http://resources.arcgis.com/en/help/silverlight-api/apiref/api_start.htm?ESRI.ArcGIS.Client~ESRI.Arc...

[DominiqueBroux]

You are right the renderers are part of LayerDrawingOptions and not of DynamicLayerInfos as I suggested.

To get the renderers defined at server side you can use GetDetails or GetAllDetails.

Additionaly you can create new renderers by using the GenerateRendererTask.
There is a sample here.

Sorry for the confusion.