GraphicsOverlay options - Any recommendations?

703
2
Jump to solution
09-07-2017 04:11 AM
JensBuchta
Occasional Contributor

I have to solve the following task in Runtime 100.1:

- Display 20 moving points in the map (Refresh-Rate 1 sec)

- The color of the point has to be changed during runtime (not based on the data)

Generally, the GraphicsOverlay(s) is clearly the way to go, but I can see three approaches:

1. Create 20 GraphicsOverlay-Instances having exactly 1 Graphic item and assign a SimpleRenderer to the GraphicsOverlay.

2. Create 1 GraphicsOverlay-Instance, having 20 Graphic items and assign a UniqueValueRenderer to the GraphicsOverlay.

3. Create 1 GraphicsOverlay-Instance, having 20 Graphic items, each one of it with a symbol assigned, no Renderer at the GraphicsOverlay.

I can see advantages / disadvantages in each of these options, that's why I'm asking for recommendations / experiences.

Option 1 is pretty easy to handle, flexible (if the customer decides to want a totally different symbol for one of those 20 items), color can be assigned easily, but having 20 GraphicsOverlay-Instances feel like a lot of resources on the map.

Option 2 seems to be a good option as well, but can get hard, if the symbol has to differ in more than just the color. Even the color itself has to be communicated to the MapViewModel.

Option 3 might consume the least resources, but in general, assigning a renderer to the layer (GraphicsOverlay) is more efficient than assigning a symbol to the feature (Graphic).

Any recommendations? Thanks!

0 Kudos
1 Solution

Accepted Solutions
dotMorten_esri
Esri Notable Contributor

For just 20 graphics only updating once a second, performance shouldn't be an issue. However I wouldn't recommend option 1 as you have to manage a lot of overlays (but overhead shouldn't be too big as at the GPU level it's more or less the same). Choose 2 or 3 whichever you find easier. You're right 3 can be more efficient since symbols can get reused, but if you have a unique value for each graphic it won't really matter. That doesn't really matter until you have a lot of graphics sharing the same symbol.

I'm not really sure about your concern about MVVM. You VM should contain the GraphicsOverlayCollection, and you just bind that on to the MapView. Then you VM is free to modify the collection and its graphics all it want.

View solution in original post

2 Replies
dotMorten_esri
Esri Notable Contributor

For just 20 graphics only updating once a second, performance shouldn't be an issue. However I wouldn't recommend option 1 as you have to manage a lot of overlays (but overhead shouldn't be too big as at the GPU level it's more or less the same). Choose 2 or 3 whichever you find easier. You're right 3 can be more efficient since symbols can get reused, but if you have a unique value for each graphic it won't really matter. That doesn't really matter until you have a lot of graphics sharing the same symbol.

I'm not really sure about your concern about MVVM. You VM should contain the GraphicsOverlayCollection, and you just bind that on to the MapView. Then you VM is free to modify the collection and its graphics all it want.

JensBuchta
Occasional Contributor

Thanks Morten for sharing your opinion, really appreciated. I think, I'll go for option 3.

I should have explained my VM concern better: I have a 1:n relation of ViewModels, in this case, I have 1 MapViewModel and 20 DeviceViewModels. The MapView is bound to the MapViewModel, of course. The DeviceViewModel is responsible for getting the data, transforming it to a MapPoint and for that point's symbology. However, I do not want any reference to the map in the DeviceViewModel.

So the MapViewModel tracks instances of DeviceViewModel and listens for changes on it.

In case of option 2, where the renderer (and the device specific symbology) is defined in the MapViewModel, the MapViewModel has to respond to changes in DeviceViewModel not only to update the current position, but also to it's symbology. In case 1 and 3, symbology is defined at the Device-level and therefore, there is no need to communicate it between ViewModels.

Thanks

Jens

0 Kudos