ThinkGeo.com    |     Documentation    |     Premium Support

Overlays and Layers Summary

#1

    Hi,


Is there any reading where I can get a top level view on the different types of overlays and their respectives usual layers?


I mean, there is LayersOverlay where the map is normally loaded, a BackgroundOverlay, on top of that there is the AdornmentOverlay where graticule and scalebar normally are placed, there are also staticOverlays, simpleMarkerOverlays, InMemoryMarkerOverlays, etc




It would be very nice to have a top level view on all the available overlays available, and what make them unique (what are designed for), so when somebody wants to plot something like tracks it will be easy to know if staticOverlay or InMemoryMarkerOverlay is preffered, a moving vessel obviously will not be in the static overlay, etc


 Regards,


Carlos.



#2

Hi Carlos, 
  
 For now we don’t have a very detail introduction for this thread. But after our Wiki product is released, I believe more and more documentation will be added there.  
  
 Actually, Overlay and Layer are two levels of object. Each overlay is a level of node in the logic tree. Such as a Canvas or a Grid. All overlays overlaping together becomes one entire map. Layers are elements for rendering an image, and then put into one Canvas. LayerOverlay is the maintainer which contains layers. All Layers in our product can only be added into this object. During drawing, it draws all the layers’ vectors into one bitmap and then paste to the Canvas of this LayerOverlay. Here is the relationship and difference between the Layers and Overlays. 
  
 Here are some special overlays such as the BackgroundOverlay you mentioned. It’s always be on the bottom level of the map. The Adornment Overlay is an overlay holds a fixed position bitmap such as scale line, logo etc. The MarkerOverlay will always on top of every overlay because it cannot be covered by other overlays for it can be drag, drop, click and show tooltips. 
  
 StaticOverlay or DynamicOverlay is obsoleted in this new WpfDesktopEdition, but you still can find it in some our other products such as WebEdition. It’s just a shortcut for the LayerOverlay with some pre-set properties. It’s just for easily using. 
  
 Hope it makes sense. Just let me know if you have any misunderstanding. 
  
 Thanks, 
 Howard

#3

 



#4

Thanks a lot Howard for your prompt reply. This brief summary is just what I needed. 
  
  So the painting order would be:  
  
 BackgroundOverlay 
 LayerOverlay 
 AdornmentOverlay 
 MarkerOverlay/InMemoryMarkerOverlay 
  
  Just one more thing; what about the InMemoryMarkerOverlay? What would be your recommendation for plotting a fleet of 1000 assets and their tracks? 
  Is there any other kind of Overlay? 
  
  Regards, 
  
 Carlos

#5

Hi Carlos, 
  
 We have three kind of marker overlays, FeatureSourceMarkerOverlay, InMemorymarkerOverlay and SimpleMarkerOverlay. First of all, let me introduce the FeatureSourceMarkerOverlay; you know we have many FeatureSource classes in our product which helps to read, query and edit datas.  
  
 For example ShapeFileFeatureSource is a FeatureSource to read and parse a ShapeFile and its related files such as SHX etc to a set of Features. Also InMemoryFeatureSource is a set of Features maintaining in the memory. You can query, edit directly from them. So FeatureSourceMarkerOverlay allows user to pass a FeatureSource which holds Point types data and convert the vectors into a real marker.  
  
 If we know how FeatureSourceMarkerOverlay works, the InMemoryMarkerOverlay is a shortcut of FeatureSource which holds an InMemoryFeatureSource. It’s just for easily using.  
  
 SimplyMarkerOverlay is kind different from the two above, it works like a container. You can directly create a marker object and add them into the overlay. It’s one to one correspondence. Which the two overlays above only maintain Features not markers. And another difference is that SimplymarkerOverlay renders all the markers on the map. It doesn’t refresh during panning. While InMemoryMarkerOverlay only renders markers in the viewport extent. So it refreshes all the time after the panning is finished. 
  
 To plot fleet on the map; we have several methods; it’s better to know their advantage and disadvantage. Here I show you two recommendations. 
  
 1, use InMemoryFeatureLayer with point style. The advantage is that it’s light weight rendering and it represents you a bitmap on the map. So it doesn’t cost too much CPU when you zooming and panning. The disadvantage is that you cannot easily implement the click event or tooltip on it unless we check the mouse position all the time in the mouse move event. 
  
 2, use InMemoryMarkerOverlay or SimpleMarkerOverlay with markers. The advantage is that you can directly set click or other mouse events on the marker object; also the tooltip is just a property to set. It’s easy, isn’t it? But a marker is actually a control which will be a not in the logic tree. If the client’s machine’s GPU is not quite good, I think it will be slow for the DX rendering too many node during Panning or zooming. But you still can have a try. 
  
 We used to have a project like your fleet tracker. Our solution is to use InMemoryFeatureLayer on the higher scale such as ZoomLevel01 to ZoomLevel06; then use InMemoryMarkerOverlay for lower scales. Because on the high scale map, the markers cluster together, and you can hardly click the right one. When in lower scales, the markers spread out and it’s convenient to click. It’s just a recommendation for higher performance. 
  
 Hope it makes sense and just feel free to let me know if you have more queries. 
  
 Thanks, 
 Howard

#6

Hi Howard, 
  
  You cannot imagine how much I appreciate your summary description and your recommendations. I’m a top-down learner, and need to have the brief global vision to feel comfortable. I’ll try the InMemoryFeaturelayer for high scale view and InMemoryMarkerOverlay for lower scales aproach. 
  
  Thanks a lot, 
  
 Carlos. 
  


#7

Howard, 
   The explanation on the various overlay types is good.  It is something I wondered about as well, and had difficulty finding information in the scattered API documentation. Your suggested solution about various zoomlevels seems like a good idea, but I am not sure how to implement this.  Would you add features to both the  inmemoryfeaturelayer and the inmemorymarkeroverlay and then add/remove an overlay depending on the zoom layer?

#8

Guys, I use InMemoryFeatureLayer with Point Style as using different layers based on zoom level sounded like too much resource use.  For tooltip, I create buffer around point and  query underlying FeatureSource for features within range and return list in grid.  To narrow down to one feature, I create a smaller buffer.  This tolerance is user configurable. 
  
 For Popup, I do something similar but use the PopupLayer.  I all cases, I create everything on the fly but typically, my queries are done on a asynchronously.

#9

Hi Guys, 
  
 Thanks for all your feedbacks. For the issue from Thomas, yes, you can add features to both InMemoryFeatureLayer and InMemoryMarkerOverlay. And both of them support ZoomLevelSet and styles. For example, you can set ZoomLevel01 - ZoomLevel06 for the Layer and 06 to 20 for the marker overlay; it just depends on the extent for your application. To find a better boundary between displaying layer or marker needs a little time to play around. 
  
 Thank you for sharing your experience again Klaus, you idea is good; for the tooltip part, we can set a timer to do the query and the timer always stops when mouse is moving and restarts again. It means the timer tick event only raises when the mouse stops; and we can avoid querying all the time when mouse moving. 
  
 Thanks and feel free to let us know if you have more queries. 
 Howard 


#10

Hi Guys, 
  
  I’m using Klaus technique and it’s working pretty well, I’m very close to discart the SimpleMarkerOverlay usage at all, as in addition it’s “preparing” have to be done in the GUI thread, while with InMemoryMarkers you can do it asynchronously and then Refresh in the GUI thread. For different icon and tracks styles I use different layers with different styles. Hence I have only one “Tracks” overlay with about 6000 layers. 
  Pan use to take long time (from 0,4 to 1,2 secs), but I will work in performance later. 
  
  My problem now with this technique (query underlying FeatureSource based on the position) is that at Zoom1 or 2 I also get features that are not visible until Zoom10. Is there any way to know if a Feature returned by the GetFeaturesNearestTo (or similar) are visible in the current extent/zoomLevel?

#11

Carlos, I have not looked into this but each layer must know its current zoom level or scale to determine what styles to apply.  So maybe you can tap into this when deciding what feature layers to query for.  You may have to pass the zoom level or scale to you method doing the query.  I see myself doing this down the road too. 
  
 Just some more notes on dynamically creating maptips, I see you are using GetFeaturesNearestTo.  Sounds like you have success with this query method.  For some strange reason, I could not get this to work reliably for me, so I ended up using Intersects, which posed its own challenges, some of them solved using predefined search tolerance levels based on map scale.   As for mouse move, make sure you are using a Timer and not handling every single mouse move otherwise map performance will be compromised.  This probably explains why your panning is taking that long. 


#12

Hi Klaus, 
  
  No, I’m using the typical “Lazy” timer that resets everytime the mouse moves for quering. The pan and zooming I’m testing with keyboard arrows, so no mouse move in here. 
  I haven’t yet started to investigate the performance issue, maybe next week. And fortunately I’m not yet with the final app, just playing in a sandbox with my “hello world” project until I have a clear picture of all the building blocks I will need. So for performance testing I can remove the mousemove element, and probably I will build an automated test module that averages the panning time based on a incremental-autogenerated number of random points. I’ll come back to you with the results later next week. 
  
  My first concent has been how to plot the tracks as I need custom icon and line properties for each of them, so I have been playing with markers, InMemoryFeatureSources, etc…

#13

Hi Carlos, 
  
 For a specified feature layer, Feature Source represents data, and zoom level uses styles to determine how the features are displayed. The data and style are divided.  So we can’t tell if a feature is visible in the current zoom level. 
  
 To query features which are visible in current zoom level, the following steps are for your reference: 
  
 1. For each feature layer, use method “GetZoomLevelForDrawing” to determine whether the zoom level is null or not at current extent, then query the feature layer by using some method (such as GetFeaturesNearestTo) 
  
       ZoomLevel zoomLevel = layer.ZoomLevelSet.GetZoomLevelForDrawing(wpfMap1.CurrentExtent,wpfMap1.ActualWidth, wpfMap1.MapUnit); 
       if (zoomLevel != null) 
       { 
           //query the feature layer           
       } 
  
 2. Use a collection to store all the found features, then use your own condition to determine which features are the final query results (for example, minimal distance with the clicked point). 
  
 Hope it make sense, please let me know if you have any questions and thanks for Klaus’ sharing. 
  
 Thanks, 
 Howard

#14

 Posted By Howard on 10-05-2010 03:37 AM 

…

If we know how FeatureSourceMarkerOverlay works, the InMemoryMarkerOverlay is a shortcut of FeatureSource which holds an InMemoryFeatureSource. It’s just for easily using. 


 


   Hi Howard,


  Just a few more questions on this



        
  1.  I’m wondering now if there is any difference between ussing a InMemoryMarkerOverlay or just use an LayerOverlay with InMemoryFeatureLayers with features loaded in it’s InternalFeatures property.

    2.     
  2.  When is it recommended to Open and Close the InMemoryFeatureLayer? For adding internal features seems not to be necessary.

    3.     
  3.  When is it recommended to BuildIndex of the FeatureLayer, every time we modify it? or just once at the beginning?

    4.     
  4.  By using InMemoryMarkerOverlay the features are added (between a BeginTransaction and CommitTransaction), what is the difference between doing so and adding the features to the InMemoryFeatureSource.InternalFeatures?

    5.     
  5. Why is not neccesary to begin and commit a transaction with the InternalFeatures approach?


  Best Regards,


Carlos.



#15

Hi Carlos,  
  
 Thanks for these questions; I reviewed your questions several times and found most of the questions are about InternalFeatures collection. Please see my commends below. 
  
 1,  using InMemoryMarkerOverlay and using LayerOverlay with point styles is similar like using System.Windows.Shapes and WriteableBitmap. It’s a relationship between rich weight and light weight rendering. 
  You know marker is actually a control, and you can set anything to its content property; you can use binding, style and events. While use layer, it actually draws as a bitmap. We don’t use any WPF features to affect this bitmap; for example, you cannot add user controls into a marker, you cannot set context menu on a specific point etc. So this is the core difference. 
 2,  For adding InternalFeatures, it’s not necessary to call Open and Close. From the layer to the data; We can easily think it has 3 levels (see the diagram below). InternalFeatures is a tube directly connects between layer and data. A simple example is that, when we use another projection like “EPSG:900913”, but the data source is “EPSG:4326”, we will always get the raw data source in “EPSG:4326” while it returns projected features using QueryTools. This is the difference. 
  
 FeatureLayer (Style, ZoomLevel) 
 |^ 
 V| 
 Projection (Convert from the source data to another projection) 
 |^ 
 V| 
 FeatureSource (Data) 
  
 3,  It’s recommend to rebuild the featureLayer when the source data is changed or else some function might be not right. 
 4, If you understand my commend 2, this one will be very clear. When we using EditTool, we need pass the feature in external projection while InternalFeatures, you need pass the feature in the original projection. 
 5,  This is also related to commend 2. We don’t need make it transition to a tube. 
  
 Hope it makes sense and feel free to let us know if you have any more queries. 
  
 Thanks, 
 Howard 


#16

 Posted By Howard on 10-05-2010 03:37 AM 

Hi Carlos, 



If we know how FeatureSourceMarkerOverlay works, the InMemoryMarkerOverlay is a shortcut of FeatureSource which holds an InMemoryFeatureSource. It’s just for easily using.  



SimplyMarkerOverlay is kind different from the two above, it works like a container. You can directly create a marker object and add them into the overlay. It’s one to one correspondence. Which the two overlays above only maintain Features not markers. And another difference is that SimplymarkerOverlay renders all the markers on the map. It doesn’t refresh during panning. While InMemoryMarkerOverlay only renders markers in the viewport extent. So it refreshes all the time after the panning is finished. 


 


  1. Based on this I understood SimplyMarkerOverlay was the rich weight as Markers are controls, and InMemoryMarkerOverlay was a Layer with CustomStyle for light use, not controls here… that’s why my question is what’s the difference between InMemoryMarkerOverlay and InMemoryFeatureLayer. InMemoryMarkerOverlay don’t use markers, but FeatureSources, with some kind of CustomStyle (how do you add the tooltip to a Feature?), and it has some custom properties that a InMemoryFeatureLayer doesn’t have.


 2. So InternalFeatures would be in the projected (FeatureLayer) side, and the external side is the DataSource, right?


 3. Ok, I’ll do it that way. I understand that if no RebuildIndex is done at all, spatial queries will just take longer, or will be unacurate as well as if It’s done once and not updated after data changed?


 5. Understood, then transactions are only required when accessing the real DataSource.



#17

Hi Carlos, 
  
 You got my point what I said in my last reply. For the first issue, I want to give you more information. InMemoryMarkerOverlay is also rich weight overlay. On the visual part, it actually holds marker controls but maintains features on the code behind. It is one way from data source to the real marker control. For the SimpleMarkerOverlay, it maintains markers on both of visual and logic part.  
  
 You might ask what is the advantage of the InMemoryMarkerOverlay if we have the simple marker overlay already. I would say, if you have a point shape file, and want to make them as markers and set different styles, it’s easier than using creating marker object directly in the SimpleMarkerOverlay. On the other hand, we can extend marker style in the future for example: class break style, value style and cluster style. 
  
 Hope it makes sense and feel free to let me know if you have more queries. 
  
 Thanks, 
 Howard

#18

Cristal clear now. 
  
  Thanks a lot for your priceless help. 
  
  Regards, 
  
 Carlos.

#19

Hi Howard, 
  
  Regarding  
  
 4, If you understand my commend 2, this one will be very clear. When we using EditTool, we need pass the feature in external projection while InternalFeatures, you need pass the feature in the original projection.  
 5, This is also related to commend 2. We don’t need make it transition to a tube.   
  
  I thought I understood it, but I spot in the HoDoI sample of a eficiently moving plane that you use a InternalFeature point shape as a the plane position, but then you need a transaction to update it. If the InternalFeature is in the proyected side (internal), why is neccesary to update the datasource (external)?

#20

Hi Carlos, 
  
 Thanks for your careful. In theory, they are the same in this case. But normally, we recommend users use QueryTools and EditTools if they do not sure about the difference between them. Use internal features, it is more flexible and we can use one line of code instead of calling Open/Close, Begin/CommitTransaction method. I think this is our laxity causes this issue. Thanks for reminding and I have modified the how do I Samples code to avoid the confusion to the other users. 
  
 Thanks, 
 Howard