High Level Project Tree

[joewheaton]

Background

Similar to #22 and this scoping doc, we have been struggling with the organization and labels of the tree. I would like to propose we agree on the parent and first-order level of the tree first. Then we can use other discussions to work through the sub-contents of the tree there-in. I think this will be easier than trying to "agree" on entire tree at once. Then we can compartmentalize our discussions. For example, I think we're pretty happy with the current Design Container. However, that container could be moved around in the tree.

Version 0.1.1

The current v 0.1.1 has a tree that looks like this:

Obviously, the first order (below the project parent container) are:

• Project Extents - Currently just simple polygon masks for clipping inputs imported into Project Layers (aka Scratch Space) that can represent a. project extents, b. watershed extents, c. property boundaries, d. etc.
• Project Layers - Currently only allows importing of feature classes that are clipped to a selected project extent. Eventually will expand to allowing import of rasters and clipping as well as import of a specific layer in a Riverscapes Project.
• Low-Tech Designs - A First working version of designs is handling really well the concept of multiple designs that represent either specifications or as-builts, and allow design of structures, grouping of structures into complexes, and articulation of Zones of Influence as design hypotheses.

If you refer to the this scoping doc,
Other suggestions at this level to add to above include:

• Riverscape Definition - Specification of valley bottom masks and segments to be used as basis for sampling assessments or designs in analyses.
• Assessments - Snapshot assessments that represent an assessment at a point in time (e.g. now, historic, recovery potential, as-built, future, after floods, monitoring events, etc.). Assessments are the mapping of things like dams, jams, innundation extent, proportion active, thalwegs, junctions, geomorphic units, etc.
• Analyses - Analyses represent sampling of an assessment or multiple assessments (i.e. through time) using the sampling frame of a mask (e.g riverscape segments). They can be used to create metric or indicator tables where rows are the metrics or indicators, and columns are the assessments (time). A new table (or tab in a spreadsheet) gets created for as many segments as there are defined in a riverscape (e.g. for each reach segments)

For Reference - GCD

GCD trees look like this.

For this discussion, the first level of the tree is:

• Project
  • Inputs
  • Analyses

The Question

As we move forward, what do we want the high level tree to look like? Perhaps we (@nick4rivers and @philipbaileynar) can propose various answers below and discuss?

[joewheaton]

One suggestion could be that we adopt a sort of GCD-like high-level grouping of

• Inputs
• Analyses

@joewheaton likes nested trees (to a fault), but I really like having something that at a high level simplifies down, really simply. For example, with above, if the default is collapsed down, then we're looking at something that is really not very cluttered. We also have the powerful concept in Riverscapes projects and in GCD of repeaters. These ARE NOT repeaters (inputs and analyses), they are just containers (i.e. unique bins for either unique content or repeater content (e.g. multiple DEMs).

Crosswalk from Existing

• Inputs - This would be where all Assessments go, all Context, and all Sampling Frames go, which are subsequently used to support analyses. Stuff in this category can still include useful tools, mapping, digitizing, attribute calculation, summary statistics, etc. However, this is where we catalog the basis (e.g. aerial photos and photos) for mapping of features at snap shots in time in assessments, and the subsequent analysis and/or sampling of that mapping.
• Analyses - Analyses are where sampling and summarization (e.g. into indicator tables, or inter-comparison tables, etc.) is done).

Crosswalk from GCD

One thing we have discussed is that GCD and GUT may eventually find a home (when funding comes) in QRiS. If that happens, it is worth making sure that whatever we decide now would accommodate that. The nice thing is that GCD is already organized this way so what goes underneath each heading would just get mapped across at this level.

• Inputs - This would house (may be further nested or collected, but):

  • DEM Surveys (may go under Assessments)
  • Reference Surfaces - Techncially these are derived from either a constant surface specification or from existing DEM Surveys
  • Masks - This is a little polygon mask library of AOIs, Regular Masks, and Directional Masks (e.g. riverscape segments with topology)
  • Profile Routes - This is a little polyline library of transects, long profiles and other paths used to extract values off of underlying "surfaces".

• Analyses

  • Change Detections - Between DEM Surveys and/or References currently (later could include others)
  • Inter-Comparisons - Across change detections or sensitivity analyses

[nick4rivers]

@joewheaton - thanks a ton for laying this out. This is fundamental to progressing forward. It is not only the high - level tree but the function and inter-relationships among components in the tree.

We really need to do this together as we have all taken a lot of time to lay out different version of this that don't fit a shared vision.