MeasureAction Enhancement Requests

JasonKnisley

After reading other threads regarding MeasureAction, I don't think I'm the only one who sees that this *could* be a very useful tool, but it's current implementation is limited and unnecessarily frustrating to work with.

I, along with others, often see a need to preserve measurements on a map.  The ability to annotate a map with measurements is one very desirable feature.  I understand that there are workarounds to handle this (at least for Polyline and Polygon... less so for Radius), but a reasonably common requirement such as this should not require a workaround.  Also, I think it's reasonable to provide programmatic access to measurements from the MeasureAction (each captured as a ESRI.ArcGIS.Client.Behaviors.Utilities.RotatingTextSymbol).  Consider a map where a user draws multiple boundaries (using the Polygon mode of the measure action).  It would be nice to know the aggregate area without the user having to pull out a calculator and manually sum the result of each measure action.  This could be easily accomplished if the area were publicly accessible.  Having access to MeasureAction properties which store the lengths and areas would be very useful.  Currently doing this would first require implementing a workaround to save the various polygon graphics, and then it would require sending those geometries to a Geometry Service to calculate the area... prior to MeasureAction this was the only option, but now that there is built-in code that has already calculated the area, having to call a Geometry Service is needlessly time consuming.

A previous thread here states that

MeasureAction is designed to remove the graphic from the map after it is done. Should you need the graphic to stay in your map, you can use Draw object for that. Retaining the graphic drawn with MeasureAction is not supported.

  No offense is intended here... I feel that the Silverlight team has built a great API, but I also feel that this is a short-sighted response and does not reflect end-user needs.  Ideally, I think it makes more sense to have MeasureAction provide all of the functionality of Draw, and then deprecate Draw.

In any case, here are a couple things which I think would make MeasureAction significantly better:

1. Provide a mechanism for programmatically accessing measurement values
2. Add a boolean attribute (AutoClearGraphics?) that controls whether or not the MeasureAction graphics layer is automatically cleared (as well as a method to manually clear the graphics layer), or at least make the graphics layer public
3. Must less important, but also useful:  allow the MarkerSymbol (used for midpoints) to be set in the same way that we can now set the FillSymbol and the LineSymbol.

With regard to number 2, that would make it significantly easier to preserve graphics.  Otherwise, it just forces the unnecessarily complicated workaround of:

1. Attach an event handler to map.Layers.CollectionChanged
2. Execute the measure action
3. In the Layers_CollectionChanged event handler, detach the handler and then assign e.NewItems[0] to a local GraphicsLayer variable.
4. In the Layers_CollectionChanged event handler, attached an event handler on graphicsLayer.Graphics.CollectionChanged
5. In the Graphics_CollectionChanged event handler, if Action == Add then copy the graphic to a local list.  If Action == Reset then iterate through the local list and add each graphic to a local GraphicsLayer.

Additionally, those steps above only work for Polyline and Polygon.  Radius requires a completely different workaround since its graphics are persistent (it will never raise the Graphics_CollectionChanged event).  Also in the case of the Radius, since its graphics are never cleared, you can never move them to your own graphics layer.  Instead, you have to make copies of the graphics.  There is no good way to do this, since RotatingTextSymbol is internal you cannot make a copy of it.  Therefore, if you try to maintain multiple Radius measurements the measurement values for all of them will reflect the last measurement.

MeasureAction is poised to be an incredibly useful tool, but these limitations are begging to be addressed.