Guys, in all your samples you wrap each layer into a LayerOverlay before adding this to the map. Looks like a LayerOverlay is not a light object.
Should we be wrapping each layer into a LayerOverlay object or should we have one LayerOverlay object into which all layers are added onto the map?
What is your best practice? I am trying to create factories for my layers and need to decide if my factories should be returning LayerOverlays or layers.
Thanks again.
Klaus
Klaus that is a very good observation. I am also thinking the same. If i want to show some feature and also hide it based on the user interaction, i need to put the feature layer to a overlay. There is no way to refresh a feature layer.
Hi Klaus, Raquibur,
I think first of all, I’ll explain what the relationship between overlay and layer is. Let’s say LayerOverlay holds a collection of layer. For a control, Overlay is a node in the logic tree in the Wpf; it’s an entire entity. While layer is an element for drawing image and fill the overlay.
In the previous Desktop, all overlays draw on one image so that when you refresh one overlay or a layer, it causes the entire map image refreshes. But in this Wpf Desktop Edition, it won’t. It just refreshes an overlay which holds the layer and it saves some performance. That’s why we need to refresh an overlay when one of its layers changed. You still can have one layer in the LayerOverlay so that you can refresh it when it’s changed; but I really don’t recommend doing that.
I think you have noticed that in this WpfDesktopEdition, you can continuously panning and zooming, that’s because the LayerOverlay is filled with tiles. Let’s say your application is 800*600 size, to fill the whole map, we need 4*3=12 tiles. Or your application might be bigger and more tiles are needed. Then you have 4 layers, so now we need 4*12 tiles. Here is the problem, in Wpf, when the logic tree is bigger, the visual part will be slower; in another word, your panning operation will become slower and slower. So we don’t recommend user to add too many overlays but nest un-frequently changed layer to one overlay with multiple tile mode; then put frequently changed layer to an overlay with single tile mode, and it’s really optimize your map’s performance.
Hope it makes sense and let me know if there is anything confusion.
Thanks,
Howard
Very good explanation, thank you Howard. I need this information to better design my layer factories. Please keep this thread open as I will be coming back to it with questions.
Klaus,
I’m glad the explanation helped.
The thread will stay open but we usually respond back so that it goes off our radar of unanswered forum posts. Once you post to this thread again it will show up on our reports.
David
Posted By Howard on 07-27-2010 08:25 PM
I think you have noticed that in this WpfDesktopEdition, you can continuously panning and zooming, that’s because the LayerOverlay is filled with tiles. Let’s say your application is 800*600 size, to fill the whole map, we need 4*3=12 tiles. Or your application might be bigger and more tiles are needed. Then you have 4 layers, so now we need 4*12 tiles. Here is the problem, in Wpf, when the logic tree is bigger, the visual part will be slower; in another word, your panning operation will become slower and slower. So we don’t recommend user to add too many overlays but nest un-frequently changed layer to one overlay with multiple tile mode; then put frequently changed layer to an overlay with single tile mode, and it’s really optimize your map’s performance.
Hi Howard, when you say that with 4 layers you need much more tiles you really mean with 4 overlays, right? If I understand it correctly all the layers within a overlay are mixed together to create the overlay "bitmap" that is tiled among other overlays, right?
Hence you can have a "Map" overlay with 3 or 4 layers making the background, the adornmentoverlay and the markersoverlay (made of maybe dozens/hundreds? of layers) and you will have 3 overlays * 12 tiles only, right?
An additional question: the overlay information that is out of the current extent adds the same performance penalty that the one is in the view extent?
Hi Carlos,
You are right, it’ a typo :)
About the second question, actually only Overlays that inherit from TileOverlay have tiles inside them. AdormentOverlay and MarkerOverlay inherit directly from Overlay, so they arrange their own contents on a Canvas without the help of any tiles. So in your case, where will be only 12 tiles.
About the additional question: the Overlays out the CurrentExtent don’t draw, so they don’t add performance penalty. We do have buffer zones and stuff which draws the feature of the current extent, but basically, that applies to most cases.
Regards,
Tsui
Howard, just a comment you guys have to capture in your Wiki and prevent others going down the wrong path.
You have to publish some sort of best practice for using LayerOverlay and Layers. We just deployed a version to our customer where we were creating one LayerOverlay per layer. It turns out this is an overkill as for 10+ OverLays, there is a significant performance degradation.
I have changed our application to recycle LayerOverlays, so I have an Overlay for all multiple tiled typed 'layers' and another for all single tiled 'layers', reducing LayerOverlay consumption to 2 and performance is a lot better.
Absolutely agree with Klaus, I spent lot of time figuring out the components of the MapSuite (layers, overlays, diferent kind of overlays and so on), and making performance test in order to “discover” that 200 layers on a overlay in order to draw individual objects (icons with associated tracks) with their own style didn’t work, and I had to use one layer with customstyles… a Best practices manual for this and general things would be highly appreciated.
I haven’t checked the wiki for a long time now, but last time I looked for something my impression was it was filled up with “auto-generated” documentation, instead of usefull descriptions and notes. I found in the forums more helpfull info, but the drawback is it take many time to read all in order to figure out how the things work.
Hi guys,
Many contents of the wiki site are the API documentations that we ship with our product.
We totally agree with you about adding some “man-made” articles to the wiki site, this would make the wiki site more helpful.
We’ll work on that when we have finished other higher priority tasks.
Regards,
Tsui