WebRAVE: Measure Tool & "Summarize Within" would be extremely helpful

[AldenShallcross]

Consider adding a measure tool and "summarize within" functionality so that practitioners can use WebRAVE solely to streamline the workflows needed to estimate values for the primary questions that the projects were intended to facilitate (e.g. the variables on the riverscape health spreadsheet). For example, within my area of interest (user defined area or simply a collection of existing, pre-delineated reaches), how many acres/miles of active channel, active floodplain, inactive floodplain, etc. do the models estimate? Perhaps a starting point would be computations for the associated variables that are listed in the Riverscape Health spreadsheet. When we did this exercise during the Riverscapes Consortium meeting on riverscape health (11/2021), our group used WebRAVE to visualize the data, Google Earth to digitize the various units, and Excel to calculate the statistics. Streamlining this within WebRAVE would save time and likely make more sense to the common user.

[MattReimer]

@AldenShallcross There are going to be limits to what we can measure in the web. Things like rulers and drawing rectangles or even polygons to measure area are easy.

Anything to do with the area of a vector shape is not going to work in the client because shapes are split between tiles and those tiles may or may not be loaded.

If we want analysis of areas, perimeter etc we need to pre-compute them in the model so that we can simply read that property in the client. These discussions will have to happen on a per-project basis or if there's something we need globally maybe webRAVE could include a pre-compile step when it is building tiles to bake this in.

[joewheaton]

@AldenShallcross There are going to be limits to what we can measure in the web. Things like rulers and drawing rectangles or even polygons to measure area are easy.

Yay! So lets do that.

Anything to do with the area of a vector shape is not going to work in the client because shapes are split between tiles and those tiles may or may not be loaded.

Understood... But what about common information query buttons?

If we want analysis of areas, perimeter etc we need to pre-compute them in the model so that we can simply read that property in the client. These discussions will have to happen on a per-project basis or if there's something we need globally maybe webRAVE could include a pre-compile step when it is building tiles to bake this in.

See suggestion below on half-way house of summarizing by pre-defined areas of interest that are already in RS_Context and tying it to the reporting functionality instead? Then funneling the custom "summarize within" stuff (i.e. a Zonal Statistic) to RiS.

[joewheaton]

Found that one from @nick4rivers: https://github.com/Riverscapes/rs-web-monorepo/issues/178

[joewheaton]

These are great @AldenShallcross. You're obviously coming from the perspective of supporting the workflow that you see people wanting to use these tools. Your suggestions are in keeping with what we're imagining for Riverscapes Studio (RiS). That is, a workflow for looking at your riverscapes. Right now, our only real web experience for experiencing these projects is WebRAVE. So it is tempting to want to put everything in WebRAVE. RAVE is just where we visualize and explore. Here's what I would suggest we ask for in WebRAVE:

• Add a measure tool, that allows user to do what they do in other webGIS environments (i.e. draw polyline and know its length, draw polygon and know its area and perimeter). This allows basic measurements for quick inquiries. A really nice feature would allow a copy results to clipboard and an export as geojson.
• Add a scale bar. Although we now show a zoom level, we don't actually show a length scale bar. Default will be m/km depending on zoom level with option to switch to ft/mi.
• Add an information query button, that allows you to click on any vector feature and see it's attributes from the attribute table, and the pixel value of a raster cell. @jtgilbert and @nick4rivers already suggested this.
• Allow reporting (html report) for pre-defined spatial queries other than just full extent of data. So right now we just view report and summary tables, statistics, graphics can be automatically generated from the full extent (i.e. watershed) of the analyses. We could allow user to right click on report and view:
  • Full Summary for Entire Area
  • Pick a HUC 10
  • Pick a HUC 12
  • Pick a HUC 12
  • Selection of network (e.g. perennial, intermittent, ephemeral, canals, etc)
  • Selection based on Land Management area (e.g. BLM lands)
• Allow exporting of any Report to Google Doc or as PDF
• For more custom "summarize within" funnel users to QRiS for now and RiS eventually.

It is important that we don't let RAVE turn into the place people come to do the more detailed stuff. Its a viewer. However, it is logical for people to expect more, so we just need to a good job of funneling them to the right places where we invite those more involved tasks. The "Summarize Within" tool is essentially a zonal statistics tool and that is reasonable to do when we limit the size of what can be looked at (e.g. < 5 miles of riverscape typically 1 - 25 riverscape segments) and is exactly what makes sense in a desktop GIS and may be doable in web if scope is more limited. See: Riverscapes/QRiS#43

[jtgilbert]

An example of where an Identify button would be really useful is here:

There's no way to know just by looking at the (massive) legend, what classes are being displayed in the map.

[MattReimer]

This is raster data. At present there is no way to read a raster value inside webRAVE. I agree this is not great but we don't have a lot of choices here. Maybe someday we can read raster pixels but for now we can't.

[joewheaton]

This is raster data. At present there is no way to read a raster value inside webRAVE. I agree this is not great but we don't have a lot of choices here. Maybe someday we can read raster pixels but for now we can't.

Surely other webGIS platforms have ways around this? Given we know that we're going to want this for Riverscapes Studio, we should think about things we can do that will work in both (not immediately, but in near future). It seems like based on cursor position at a minimum you can figure out coordinates? If that's the case, maybe (for a number of uses) having a simple API that can access any raster layer in the warehouse and return its pixel values is something worth looking into.