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.

[joewheaton]

@philipbaileynar it seems like this discussion might need to be moved to RiverscapesXML? Also, are their actionable tasks out of it that need to get updated to work for QRAVE, ArcRAVE and WebRAVE? This will become relevant moving forward for all our geopackage based network runs.

[philipbaileynar]

Next step is that I need to convince @MattReimer that this is a good idea, then discuss potential impacts.

One wrinkle that I anticipate... I'm not 100% certain, but my recollection is that query strings use slightly syntax depending on the data storage (shapefile, file geodatabase, geopackage, postgis). Sometimes field names are double quoted, sometimes square braces. If indeed this is true, business logic query strings will not be universal, which would scupper this whole approach.

[MattReimer]

It's a promising idea but lots to investigate. We need to make sure that the syntax for ArcGIS and qgis are the same. Querying being different for different data types shouldn't be too big an issue because a given node will always load the same datatype.

Also this will never work for webrave without an enormous effort. Maybe that's not such a big deal or maybe we could have some sort of sensible fallback...

[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.