Latest Contributions by BrianMerson

It would be a nice to allow the ArcGIS Online swipe/spyglass story map template support more than two layers/maps. There are two options.  First, you could allow both panes to change.  Second, you could have a fixed primary pane and a changeable secondary pane.  Neither the UI or the underlying logic is particularly complex. For a fixed primary pane, you could add forward/back arrows to the spyglass oval or to the secondary map/layer pane.  These could be used to move through the available maps/layers.  The image below shows a quick mock-up of the idea.  The arrows are red just so they show up. It would be simple to extend this idea to cover the other case.  Simply place forward/back arrows in both panes of the swipe, or in the background pane in addition to the spyglass. In these designs the arrows simply iterate through the available maps/layers.  As part of configuration, you should allow the author to adjust the order of the list and select the starting items. An alternative UI approach would be a pop-up menu that allows you to choose from available maps.  This could be a single small icon located on each pane (for the swipe view) or possibly two icons in the spyglass view.  There are other options as well. One question would be whether to allow users to set both maps/layers the same, resulting in no meaningful swipe.  I would probably disallow this by simply skipping over maps/layers that were currently in use when the user goes through the switching process.  But that's a detail. The key point is the ability for the user to switch between more than two maps/layers, allowing them to be presented with a variety of maps/layers to choose from.    ... View more

I would like to see the ability to have symbols (circles, squares, etc.) with proportional area that also have graduated colors.  Essentially, this is bivariate proportional symbols, with sized based on one variable and color based on another variable.  This same capability would be useful in bivariate graduated symbol symbolization as well (size on one, color on another). Note:  This can be achieved using some field calculations and representations.  I have written up one such process in Ask the Cartographer.  However, it's much more complicated than it needs to be, and it should be easier because it is a useful technique in many situations where you want both a quatitative comparison and a qualitative comparison. One key aspect of this bivariate symbolization needs to be the corresponding symbolization of the legend entry.  It needs to be something reasonably compact, probably with symbols down the middle, size value labels on one side, and color value labels on the other side. The current multi-variate symbolization results in a table of contents that basically repeats the full set of graduated symbols for each class of the second variable.  The is both huge and ugly, a combination that makes it next to useless. ... View more

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. ... View more