Point-Based, Polyline-Based, and/or Polygon-Based Tool for creating assessment dataset

[joewheaton]

User can manually digitize features (points is simplest) that represent things like:

• Geomorphic Units
• Drainage Network Nodes (Confluence, Difluence, Trib Confl, )
• Jams
• Dams
• Shearzones
• BRAT
  These are generally our complexity metrics, and will be recorded as spatially explicit counts (default is 1, but 1 feature could represent multiple (e.g. beaver dam complex representing multiple dams), which then may be used to calculate metrics within riverscape assessment units (e.g. valley bottom reach segment) like count within assessment unit or count dividied by assessment unit length or area (e.g. dams/km)

This creates a node of the user-specified type which is a feature class inside the assessments.gpkg, and symbolizes it accordingly, and exposes it in the RS project.

[joewheaton]

@nick4rivers lets work on specing this out prior to your field work in Kern. We may even want to get this going before your trip if it is feasible. This is going to be a really big priority and core functionality.

[nick4rivers]

@joewheaton - I can start on this on Monday. It's a big but really important one and would put us really far on a big component of the RIPT vision.

[philipbaileynar]

• Users will be able to add one or more assessments to a QRiS project.
• Each assessment will have a name provided by the user and be represented on disk as a folder (see below)
• Each assessment can comprise one or more of the following:
  • channel assessment (i.e. active channel, active floodplain etc)
  • structure assessment (jams and dams)
  • geomorphic assessment (GUT)
  • inundation assessment
• Each of the four types is represented by a separate geopackage (channel.gpkg, structure.gpkg etc)
• Each of the four types will have type-specific lookup tables for tracking additional information (e.g. the structure geopackage will probably have a structure_types table for jams, dams, PALs, BDAs, boulders etc)
• Each geopackage contains a separate feature class for points, lines and polygons (i.e. structure can be collected as points, or crest lines, or polygons with an associated count).
• Each feature class will have an item_count column that indicates how many features a point, line or polygon represents. i.e. a point might have an item_count of 5, meaning it is the average location of five dams. Or a polygon with an item_count of 2 is a lasso around two dams. I'm not set of the name item_count but note that count is a reserved word in SQL and should be avoided as a column name.

User Workflows

For now, this is all about two workflows:

1. enabling the user to quickly create the assessment folder and geopackage structure within a QRiS project and getting the relevant feature classes added to the map so they can starting an edit session to add features.
2. importing existing assessment data and storing it in the same folder/geopackage structure as if they had created it directly within the QRiS project.

Note that this ticket does not include any collecting ("hoovering") of assessment data into indicators. For now, we are just focused on capturing the assessment data in QRiS.

Creating An Assessment

1. Right click on QRiS project node and select "Create Assessment" from context menu.
2. Simple (for now) form that allows the user to provide a name.
3. Assessments node gets added to QRiS project (if it doesn't exist already) with the users assessment listed underneath this node.
4. User right clicks on their assessment node and selects one of four items. This creates the necessary folder and geopackage on disk (see below) and adds the corresponding feature classes to the map ToC ready for editing.
   • Create Channel Assessment
   • Create Structure Assessment
   • Create Geomorphic Assessment
   • Create Inundation Assessment

Editing and Assessment

1. Right click on existing channel, structure etc assessment in the project tree and choose "Add To Map". The feature classes get added to the map ready for edit session.

Importing Assessment Data

We need this, but it's secondary. Let's create a separate ticket for this feature once creating an assessment is operational and the design of the geopackages has settled.

Reporting on an Assessment

We haven't discussed reporting yet. Perhaps leave this for now. I foresee this either as a section in one big QRiS report that we dynamically grows or shrinks based on what the user has done in the project. Or it's a dedicated assessment report. I prefer the former because it's less confusing for user and simpler to develop.

Deleting an assessment

Leave this for now. But we will need a right click action to remove an assessment as well as any items in the map and on disk.

Folder Structure

On disk I propose the following:

myQRiSProject
    \assessments
        \assess0001
            \structure.gpkg
            \channel.gpkg
            \geomorphic.gpkg
            \inundation.gpkg
        \assess0002
            \structure.gpkg
            \channel.gpkg
            \geomorphic.gpkg
            \inundation.gpkg

Note how each assessment has an indexed folder name and does not use the name entered by the user.

[philipbaileynar]

I talked to @joewheaton and he is open to building this feature directly in PostGIS instead of geopackages.

@nick4rivers and @KellyMWhitehead let's meet to discuss.

@nick4rivers have you made any progress on this already?

[nick4rivers]

OK - initial spec on the most simplest of data models. I'm suggesting we keep this first feature editing implementation in QRiS simple AF.

I've just specified a simple implementation of the structure.gpkg with three tables:

• It contains only two tables for features - one for dams and one for jams (wood)
• Starting with just points - we can discuss other geometries later
• A third table is just a lookup table that would be shared lookup table

What I'm asking of @philipbaileynar and @KellyMWhitehead is:

• Briefly review of the .gpkg
• Comment on naming conventions for tables and attributes, and lookup tables?
• Comment on whether a .gpkg is appropriate for starting/sharing data model specifications? or should we go straight to IDL?
• Comment on how we will handle parent tables (i.e., assessments, reach, project?) and associated foreign keys?

By Monday I should be more up to speed on the Qt and Plugin development process and we can talk about key steps for implementation of a first and very simple QRiS assisted editing implementation.

Or - if I'm way off just let me know?

Download Geopackage here?
structure.gpkg.zip

[nick4rivers]

@philipbaileynar, @KellyMWhitehead, and @joewheaton

I've started a diagram for the QRiS assessment schema: https://docs.google.com/presentation/d/1FniU3SKjqIE96LzQtZDjKF1VWL86VL_o1ePf6n_Enr4/edit?usp=sharing

As of this comment it just starts simple with structure assessment. It raises a ton of architectural questions that need to be discussed as we proceed. Please see my comments above, and all my comments in the Google slide. Hopefully we can schedule a chat in the next day or two for discussion so we can keep this going.

[philipbaileynar]

This ticket is old and supercded to where we have gotten to with data capture events, protocols, methods and layers. Closing.