Support nested drop down River Basin values and RegulatoryOverlay discussion

[amabdallah]

1. For the River Basin Area filter, we need to support nesting river basins (maybe through a plus sign next to high level basins?) as in the case of the Colorado River Basin > Upper Basin, Lower Basin.
2. For the Regulatory Area Search filter, we might end up with 100s of these values which makes it too hard for a drop down menu. Should the drop down menu itself include a search filter: example: the user types: North Platte and the drop down menu filters out anything else that does not match. What if the user want all the regulatory boundries for AZ or UT ?
3. Related to Point#2 where would users narrow down the search for WaterSourceTypeCV values (e.g., show regulator areas only for surface or groundwater). Would we use the same WaterSourceTypeCV above for water rights? what would be the limitations? Where would they filter through RegulatoryOverlayTypeCV (e..g, federal)
4. What if a user want to see all the regulatory overlays in the West, then download their shapefile and metadata? how do we support that? Under a new tab?

[rwjam]

1. For the River Basin Area filter, we need to support nesting river basins (maybe through a plus sign next to high level basins?) as in the case of the Colorado River Basin > Upper Basin, Lower Basin.

• Neat idea. We can look into doing this.
• This 'might' get’s into issues of having a drop down menu that is too large / complicated if we start defining too many river basins / include too many river basin hierarchy for a user to sort through.

2. For the Regulatory Area Search filter, we might end up with 100s of these values which makes it too hard for a drop down menu. Should the drop down menu itself include a search filter: example: the user types: North Platte and the drop down menu filters out anything else that does not match. What if the user want all the regulatory boundaries for AZ or UT ?

• Good point. In the case of too many options, a drop menu might not be the best approach.
• An Advance Tool solution might work best here. As including a filter inside another filter gets complicated and can confuse a user if we don't include some sort of step-by-step guide with it.

3. Related to Point#2 where would users narrow down the search for WaterSourceTypeCV values (e.g., show regulator areas only for surface or groundwater). Would we use the same WaterSourceTypeCV above for water rights? what would be the limitations? Where would they filter through RegulatoryOverlayTypeCV (e..g, federal).

• Good question. The Existing “Water Source Type” filter on any given tab only applies to that type of site / area data (e.g., water right sites, aggregatory polygons, site specific sites). Traditionally if we wanted to search for WaterSourceTypeCV in regulatory data, we would create a Regulatory Data tab where that tab's Water Source Type filter would search the regulatory WaterSourceTypeCV data.
• Creating an Advance Tool might be the solution. That way we can customize it for each data type where we want the ability to filter via Regulatory Area data and type.

4. What if a user want to see all the regulatory overlays in the West, then download their shapefile and metadata? how do we support that? Under a new tab?

• I would think this needs to be on it's own tab / be the result of using an Advance Tool.
• As a note, we are having the same overlap issue here with Regulatory Area polygon data as we are in Aggregated Reporting Area polygon data. Same states provided multiple area types that 'may' overlap one another.

[amabdallah]

Great points. Let's discuss this more along with any other issues early next week. I'll revisit the use cases and see how to we can meet them as we try to address these design decisions. I do hate instructions when it comes to using any dashboard. It all should be "intuitive" hahaha, to an extent.

[amabdallah]

This idea is now generalized into here https://github.com/WSWCWaterDataExchange/WestDAAT/issues/75