BRAT run versus display extent
Closed this issue · 3 comments
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:
- 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.
- 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
IsPerenfield 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.
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.
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.