Select to view content in your preferred language

Elementlayer + Zoom fail

1412
5
08-29-2011 03:28 PM
BenSainsbury1
Deactivated User
I am a big fan of the elementlayer object in the Silverlight API, but I'm coming up against a bug I can't overcome.  When zooming in to large map scales, the elementlayer appears to be there but appears to 'struggle' over z-index with the map and loses.  In the sample below, the element layer disappears at a certain point and doesn't come back.  In my application, the el layer disappears at a certain scale but then reappears at larger scales. 

The behavior is reproducible with the sample here (just zoom way in):
http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#MediaLayer

Can anyone offer some clues up on this one?
Morten Nielsen I'm looking at you.

ben sainsbury - oregon metro - portland, or
0 Kudos
5 Replies
dotMorten_esri
Esri Notable Contributor
Stop looking at me 🙂
Unfortunately I can't provide you with a solution. This is due to a bug, errr limitation in Silverlight that prevents you from stretching elements to the extreme, (basically when it exceeds 32768 pixels wide/tall, it overflows and starts the weird flashing). We have filed this bug to the Silverlight team, but the response is basically that they don't think it's possible to fix due to some very low-level things going on on the graphics card, so don't expect this to be fixed in a future version either.

We have overcome this in the graphics layer by clipping the geometry on the fly when hitting that limit, but there's no way to prevent this on an element layer, other than to tell you not to zoom that far in (in most cases I would argue that zooming that much in on a single element would stretch it so much it doesn't make sense to look at it anyway though :-).

In most cases you can actually accomplish the same with a GraphicsLayer as with an ElementLayer by using custom symbols. Have you considered this? GraphicsLayer has many benefits over ElementLayer (better performance, the mentioned clipping, wrap-around support etc)
0 Kudos
BenSainsbury1
Deactivated User
Morten,
Thanks for the timely response,:)

Sounds like it's out of the question for now...
Our UI allows the user to tweak some sliders and submit a weighted sum gp operation to the server.  Upon callback from the gp, the UI pins the new raster (png) to the map as an element layer.  It all works quite well and if this is the only problem in the workflow, I suppose I should be grateful, add a scale dependency and move on.

I can't conceive of a way to convert the returned raster from the GP operation to a graphicslayer...Are you referring to symbolizing a polygon with a raster image or vectorizing the returned raster? either or, I think, as aforementioned, I'll be grateful and move on.

Thanks for your help!
0 Kudos
DanielWalton
Frequent Contributor
Morten, can you share a snippet of that clipping-on-the-fly solution?

Thanks!

Edit: nevermind, see below.
0 Kudos
DanielWalton
Frequent Contributor
I think I've found a bug in the implementation of this workaround. When you zoom way into an elementlayer or graphicslayer, the UIelement seems to shift position and stop scaling. You can observe this on the interactive sample for elementlayer by zooming way in on one corner of the red rectangle.

This also happens with graphicslayer and this fillsymbol template:

<ControlTemplate
    xmlns="http://schemas.microsoft.com/client/2007"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Path x:Name="Element" Fill="{Binding Symbol.Fill}"/>
</ControlTemplate>
0 Kudos
DanielWalton
Frequent Contributor
After thinking about this some more, it occurs to me why this is happening. When the user zooms in far enough, GraphicsLayer clips the geometry so that the symbol does not exceed 16k pixels. Since my symbol uses ImageBrush, the image will essentially stop zooming once this happens because the symbol container is no longer growing. There must be a way to setup the symbol so that the image gets positioned (and clipped?) appropriately. This is Silverlight after all!

Thanks,
Dan
0 Kudos