"As Seen" Legend Swatches for Transparency

235
0
12-06-2012 06:11 PM
Status: Open
Labels (1)
BrianMerson
New Contributor III
It would be useful to be able to specify an actual "as seen" view as the fill for a patch in a layer with transparency.  Currently, you can enable transparency in the legend.  However, the legend patch color will simply appear as a lighter, more transparent version of the original color.  This is better than nothing, but does not reflect the real interactions with layers beneath the transparent layer.  If all of the corresponding polygons happen to be over the same color, and that color happens to be white (or the legend background color?), then this is fine.  Unfortunately, that situation pretty much never exists.

Since every map scene is different, it is not possible for the software to know what a representative swatch might look like with any certainty.  However, it seems likely that the designer would be able to select a representative patch area from the map view.  That is what I propose.

This would probably apply only to layer-level transparency for polygon layers.  It's possible that it could be useful for value-based-transparency as well, but since that is often used in a somewhat bivariate way, it may not be particularly useful unless two dimensional swatch legends are supported in a more elegant (not-graphics-based) manner.  However, if you decide to implement this, please feel free to think about the transparency-by-value situation, because an elegant solution to that problem would be great as well!

My idea is relatively simple.  Add a way for the user to simply style a patch by selecting a representative area from the view extent.  This could be done by simply going into Legend Properties, selecting the item, click Style, and select the General tab (probably the most logical place for this).  Here you would add a new interface that was enabled only if the layer was transparent.  If it was, the user could click a Select Patch From View Extent button.  This would pop up a selection cursor in the shape of the current patch shape.  The user could then navigate around the map.  When he clicked on an area, the actual view, as seen, with transparency applied with visible layers below, would be grabbed and used for the patch value.  By repeating this for each class, and clicking on a representative area of that class, you could create a much more realistic display of the transparency effect.

Ideally, this would be a "live" situation, where the selection process would store the selected location, rather than the data itself.  The patch would then need to be refreshed with each change to the map that affected the view under that layer  (well, technically, on changes that affect the view under that particular patch's selected area), e.g., a change in layers or order, other changes in symbology, etc.

There are some tricky aspects to this, for instance, deciding what to show when multiple transparent layers are stacked.  Probably you show the view from that layer down, but you could simply leave it up to the user to select a representative area that, for instance, was not overlapping with transparency.

This functionality by itself would be a huge win and would enable much nicer handling of transparency in the legend.  However, this idea could be extended in a couple ways I can think of.

First, you could use the layer and classification information to change the patch selection mode cursor to a "not allowed" shape unless it was over a polygon from the layer in question and that polygon was within the classification associated with the patch being styled.  Alternatively, when in patch selection mode you could automatically mask out areas of the view extent (or map) that do not contain polygons with the correct combination of layer and classification (or highlight those that do).  Either approach would aid users in selecting an appropriately representative patch.

Second, it might be possible to somewhat automate the process to provide potentially better defaults that the flat default patch colors.  The basic logic is conceptually simple:
 
for each classification in the legend for the transparent polygon layer
  • find area closest to the current view center, within a polygon from the layer that is within the class associated with the patch, such that the entire bounding box for the current patch shape falls within the polygon.
  • if no suitable polygon is found in the view extent, extend the search to include larger extent (out to entire map extent)
  • if no suitable polygon is found in the full map extent, use current default transparency behavior
This should find reasonable patch areas within the actual viewable extent, or as close as possible to it, assuming that the extent includes a large enough polygon of the given class.

Depending on the map, these may be fine.  However, it is likely that the user might very well want to choose a different location for the patch.  The original patch selection ability proposed above provides this capability.  If the automatic patch location works, great.  If not, it can be overridden just like any other patch.

The automatic default transparent patch selection feature could be enabled for the layer from the same location where layer transparency is enabled (this would be a layer-by-layer setting), or you could make it an application-wide setting and set it the same place where you currently enable/disable transparency in the legends.  Either way would work fine.  When disabled, you get today's default transparent patch behavior.

By the way, some of the patch selection functionality might also be used for other patch selection purposes if you chose to allow it (for instance, it might be interesting to select a representative image sample for a land-cover patch).  Since the underlying functionality would be basically the same, it would just be a matter of deciding where else it might be useful and enabling it in the UI as appropriate.  Just a thought.  This is a potential extra benefit from possible shared code, the request is really for the transparency issue.