This issue is not currently a high priority. The current event handling generally works so use it until there is time to do a more substantial redesign. Use this issue to collect requirements and ideas for redesigned event handling.
Recent work on the event handlers and popups have identified the need to redesign event handling. The following are design considerations:
The design should accommodate typical user interactions such as hovering over a map feature and clicking on a feature. It may be necessary to support more complex interactions such as Ctrl-click.
Need to implement default event handlers for mouse layer hover and click similar to the current functionality, which displays all attributes for the feature.
Need to allow one or more event handlers for hover, such as display attributes, highlight single feature, and highlight multiple features (such as upstream reaches or basins, related data, etc.). Multiple events may need to occur at the same time (display attributes and highlight features).
Allow direct-click action, such as click on feature and display graph or other output without intermediate popup. The InfoMapper does not current do this because it displays an intermediate dialog (next item).
Continue to allow popup with attributes and buttons, requiring second click to show graph. This is the current InfoMapper design.
The event configuration JSON should ideally handle the above in a single file, possibly as a separate file and possibly to be included in GeoMapProject json. Need to keep in mind that different applications such as InfoMapper and desktop map viewer may use the same configuration file(s) but are implemented with different software.
I also ran into another situation that cannot be handled with the current InfoMapper design. The InfoMapper needs to display a graph that shows a municipality's total population and the split of that population when the municipality spans multiple counties. There are 21 municipalities in Colorado out of 271 that have this situation. The problem is that the general graph template can't be used for those municipalities, and we don't want to show an empty time series for the 250 other graphs. The graph template (or even location-specific graph configuration) may be different depending on location. Therefore, the click popup dialog needs to use a different configuration depending on location, maybe 21 specific configurations and a default for the rest.
Based on all of this, I am thinking that event handling should be similar to URL-routing in concept. The idea is to implement something like the following:
An event handler is configured for the layer. This is already implemented but would need to change a bit. Multiple event types would be configured as indicated above.
When a feature for a layer is selected by hover or click, the event routing would evaluate a feature value such as station identifier or other attribute value, and based on that would implement specific event handling. For example, the code would show different popup dialog based on the feature value. Matching the feature value would use regular expression and wildcards so that defaults and specific matches could be defined.
The end result would be a more complex configuration, but would be flexible enough to handle event configuration.
This issue is not currently a high priority. The current event handling generally works so use it until there is time to do a more substantial redesign. Use this issue to collect requirements and ideas for redesigned event handling.
Recent work on the event handlers and popups have identified the need to redesign event handling. The following are design considerations:
I also ran into another situation that cannot be handled with the current InfoMapper design. The InfoMapper needs to display a graph that shows a municipality's total population and the split of that population when the municipality spans multiple counties. There are 21 municipalities in Colorado out of 271 that have this situation. The problem is that the general graph template can't be used for those municipalities, and we don't want to show an empty time series for the 250 other graphs. The graph template (or even location-specific graph configuration) may be different depending on location. Therefore, the click popup dialog needs to use a different configuration depending on location, maybe 21 specific configurations and a default for the rest.
Based on all of this, I am thinking that event handling should be similar to URL-routing in concept. The idea is to implement something like the following: