"Summarize Within" custom polygon request (i.e. Zonal Statistics)

[joewheaton]

@AldenShallcross asked for over here in WebRAVE (see also our responses): https://github.com/Riverscapes/riverscapes-website/discussions/32

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.

We should think about adding this to the feature wish list for QRiS and if it is popular/useful upgrading it to RiS wishlist.

[nick4rivers]

@joewheaton, @MattReimer, @philipbaileynar, @KellyMWhitehead,

I'd like to continue this discussion, and specifically ask the question of HOW we want to calculate zonal statistics. for a simple example, counting the number of structures within a valley bottom polygon segment. We need to consider specically how these statics will get used in summarizations, maps, metrics, reports, exports, etc...... Within Q there are probably a bunch of way to do this:

QGIS Virtual Fields

• Implemented within the .qml
• On the fly updating of calculations with any feature edits.
• Stored in memory i.e., not stored in the geopackage.
• I'm pretty comfortable with this approach.

Combination of Python packages, GDAL, and SQL

• Implemented as part of plugin code
• Would likely require triggering scripts through user actions
• Would be stored in geopackage feature classes

In actuality we will probably use some combination of the above, and there are probably a lot of other ways to go about this. Would be interested to hear ideas and pros and cons from if you all have implemented similar functionality within Arc tools and applications.

[nick4rivers]

Hey, doing some more experimenting on this front. There is a lot we can do with the default value specification within the custom form settings. We have the entire qgis calculation language at our disposal, and the values update even when geometry is edited. The calculations are also stored, not just in memory, which is really what we needed.

This will all be specified within the .qml, so it's difficult to version control, but it's really rapid in terms of development.

[joewheaton]

Very interesting @nick4rivers. I think I need to better understand when (what user event or data change event) invokes these calculations in QRiS and better understand our different options.

[philipbaileynar]

If we are content that users will only ever need to see/use these values during an active QGIS session, then we can use the virtual fields.

If we ever anticipate a user needing the figures in a report or access to them outside of QGIS then we will need to store them in the GeoPackage (and HTML report etc).

As @nick4rivers said... we will probably use a combination of both.

[joewheaton]

@philipbaileynar I am rekindling this request from Alden. This seems like a good command for both the Tools (Non-Project) and something to be accessed in 'Analyses` as right-click command. The output would just be a simple little zonal stats report.

[philipbaileynar]

Definitely makes a nice future feature. The idea would be a quick and dirty "geospatial summary" of layers in the map ToC. In other words I don't want to create an official data capture event, mask and see curated metrics. I just want to summarize GIS data by some cookie cutter/lasso.

I foresee a workflow would be:

1. Add a polygon layer to the map.
2. Add any other raster or vector layers to the map.
3. Click a button on QRiS toolbar to "Summarize Layers". Form pops up:
   • dropdown to select which polygon layer is the sampling frame
   • tree control with checkboxes to select which layers (and attributes) to summarize.
4. JSON or HTML file written to disk with output.

Notes:

• Need checkboxes to pick feature class attributes (because things like NHD have dozens of attributes, many of which don't make logical sense to summarize).
• This is "dumb" geospatial summary based off map ToC. Count this... measure that... No intelligence needed about what a layer "means". It's just points, lines, polygons and rasters.

[joewheaton]

This feature @philipbaileynar forsaw was nicely implemented in 0.4.1