BRAT run versus display extent

[philipbaileynar]

We run BRAT on a limited set of FCodes:

33400	CONNECTOR	Connector	feature type only: no attributes
33600	CANAL/DITCH	Canal - Ditch	feature type only: no attributes
33601	CANAL/DITCH	Canal - Ditch	Canal/Ditch Type|aqueduct
33603	CANAL/DITCH	Canal - Ditch	Canal/Ditch Type|stormwater
46000	STREAM/RIVER	Stream	feature type only: no attributes
46003	STREAM/RIVER	Intermittent	Hydrographic Category|intermittent
46006	STREAM/RIVER	Perennial	Hydrographic Category|perennial
46007	STREAM/RIVER	Ephemeral	Hydrographic Category|ephemeral
55800	ARTIFICIAL PATH	Artificial Path	feature type only: no attributes

In other words, we get features in the BRAT output ShapeFiles for all these FCodes, but no others (e.g. coastline and pipelines are entirely absent from the output ShapFiles).

In this video, @joewheaton points out that the default views of BRAT results should be further constrained to just perennial and artificial paths. BRAT results should still be calculated for all other FCodes, just not part of the default display. There are two ways to achieve this:

1. Produce 2 output Shapefiles, one with only perennial and artificial paths and another with all the FCodes listed above. For the record, I despise this approach. I have worked tirelessly to reduce the duplication of data produced by BRAT so as to avoid confusion and mess.
2. Write an additional attribute to the Shapefile that flags each reach for display in the "Perennial" result set or "entire" result set (these labels could be anything). Perhaps the IsPeren field achieves this already? We can investigate. Anyway, the goal is to make it quick and simple to display different result sets and not require each layer file to manually specify the list of FCodes involved.

[joewheaton]

I like option 2 much better. You're right, it should be a display and query for summary purposes issue, NOT where we run issue.

…

_____________________ Dr. Joseph M. Wheaton 435-554-1247 (direct) | http://www.joewheaton.org

On Mon, Jul 13, 2020 at 3:28 PM Philip Bailey ***@***.***> wrote: We run BRAT on a limited set of FCodes: 33400 CONNECTOR Connector feature type only: no attributes 33600 CANAL/DITCH Canal - Ditch feature type only: no attributes 33601 CANAL/DITCH Canal - Ditch Canal/Ditch Type|aqueduct 33603 CANAL/DITCH Canal - Ditch Canal/Ditch Type|stormwater 46000 STREAM/RIVER Stream feature type only: no attributes 46003 STREAM/RIVER Intermittent Hydrographic Category|intermittent 46006 STREAM/RIVER Perennial Hydrographic Category|perennial 46007 STREAM/RIVER Ephemeral Hydrographic Category|ephemeral 55800 ARTIFICIAL PATH Artificial Path feature type only: no attributes In other words, we get features in the BRAT output ShapeFiles for all these FCodes, but no others (e.g. coastline and pipelines are entirely absent from the output ShapFiles). In this video <https://youtu.be/hvh0yYJ_9SQ?t=2601>, @joewheaton <https://github.com/joewheaton> points out that the default views of BRAT results should be further constrained to just perennial and artificial paths. BRAT results should still be calculated for all other FCodes, just not part of the default display. There are two ways to achieve this: 1. Produce 2 output Shapefiles, one with only perennial and artificial paths and another with all the FCodes listed above. For the record, I despise this approach. I have worked tirelessly to reduce the duplication of data produced by BRAT so as to avoid confusion and mess. 2. Write an additional attribute to the Shapefile that flags each reach for display in the "Perennial" result set or "entire" result set (these labels could be anything). Perhaps the IsPeren field achieves this already? We can investigate. Anyway, the goal is to make it quick and simple to display different result sets and not require each layer file to manually specify the list of FCodes involved. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/Riverscapes/sqlBRAT/issues/71>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACKGAAPVM4YOEXPZFZE436DR3N4A5ANCNFSM4OY4FVPQ> .

[philipbaileynar]

Thinking about this further I don't like either option shown above.

Option 1 sucks because producing 2 sets of ShapeFiles is obviously a non-starter. Data duplication should be the last resort!

Option 2 using the IsPeren is somewhat better but still requires some fiddly symbology configuration that is buried in the layer file and hard to decipher.

Option 3 - Query Definitions

Another option is to allow the business logic for each node that represents a vector to include a query definition that filters which features are included in the layer when it is displayed. This is extremely powerful and has lots of potential uses beyond this specific case.

Here is the current business logic for displaying the existing beaver dam capacity:

<Node label="Existing Dam Capacity" xpath="Vector" type="vector" symbology="oCC_EX" />

And this could be extended with a query definition to be:

<Node label="Existing Dam Capacity" xpath="Vector" type="vector" symbology="oCC_EX" qdef="IsPeren<>0"/>

This will filter out all features that are not perennial. In ArcGIS the attribute table view and all other aspects of this layer will be as if the non-perennial features don't exist. Then we can create another business logic node, nested within a folder or whatever, that shows the dam capacity for all features, simply by omitting the query definition.

This approach also benefits from being transparent. Anyone can see the query definition associated with a layer simply by looking at the layer properties in ArcGIS (below). Query definitions can be simple or complex. There's even a UI for building them in ArcGIS if people need help. The same concept also exists in QGIS using layer subsets.

[philipbaileynar]

I have implemented the query string approach on a local branch. It works. Want to discuss with @MattReimer before I incorporate it into public release.