Let's Discuss Biotic Attributes

[cybersea]

I understand the rationale for how you designed the attributes for Biotic because of overlapping types, but it is challenging to easily determine how many different final "types" are present in a polygon. Also, each column corresponds to a single CMECS code, so this could get quite overwhelming as more information or flora/faunal types get added over time.

There is also quite a bit of redundant information in the various columns. For example, if the final class is Zostera japonica, there would be an entry in four columns: BC_CLASS05 (2.5) , BC_SUBCLASS03 (2.5.2), BC_GROUP06 (2.5.2.1), and BC_COMM13 (2.5.2.1.17p). But, all of the hierarchy is actually encoded in the most detailed code, 2.5.2.1.17p

How about keeping the individual BC_CLASS## columns, so it is easy to see what high-level biotic types are there, but then simplifying to just several additional columns for each of the different (most detailed level) codes in that polygon? It wouldn't matter if they were at the same level of CMECS or not.

For example, two types of clams, macroalgae, and Z. marina in one polygon: Element01 = 2.2.2.14.2 Element02 = 2.2.2.14.5 Element03 = 2.5.1 Element04 = 2.5.2.1.16

This is similar to what is suggested in this CMECS guide for co-occuring units (p.7): https://iocm.noaa.gov/cmecs/documents/CMECS-Coding-System-Approach-20140619.pdf

It's not elegant, but maybe more concise and allows flexibility if the number of co-occurring types expands in the future.

[tchaddad]

Yep, I hear you! The real issue boils down to what gets released, vs. what is held in-house. The path you suggest is logical, but entails lots of decisions that the TAC didn’t quite seem comfortable with. In-house we have everything, and externally some people want everything, some people do not. The current design caters to both groups, but needs refinement.

Main issue at the moment is: does this affect your selection of assessment points? I was thinking that you would choose the appropriate column for each item you wanted to generate points on...

[cybersea]

Ok. This makes more sense now. Thanks for the conversation. The current design optimizes for finding a particular "thing" at any level of hierarchy in the classification. So, if you want to find out which polygons have seagrass, you just query a single column to find them all. Since each column corresponds to a single code, maybe it would be helpful to name them according to the attribute, rather than using an arbitrary number. For example, the systems could use the following abbreviations: AB = aquatic bed FB = faunal bed EW = emergent wetland SW = scrub shrub wetland FW = forested wetland

With this design, however, it is difficult to easily identify the list of ALL "things" that are in a polygon, regardless of the level of hierarchy. Still struggling with how to best approach this, since as you said, the difficulty is when you take the approach above (Element01, Element02, etc.), you may have to query multiple columns to pull out a particular "thing." Always trade-offs.
I think you're original design is probably easier to maintain, especially when you are merging in multiple data sources.

[cybersea]

Some thoughts about displaying overlapping biotic elements:

Wetlands (Classes 2.6, 2.7, 2.8) could be displayed at the highest level of detail, and logically should not overlap with any other class, so multiple elements should not be an issue. Or, they could be rolled up to a standard level of detail if that makes sense.

For Aquatic Bed (2.5) and Faunal Bed (2.2), I would suggest the following levels to roll up for a simplified legend/display:

• Tunneling Megafauna (group = 2.2.2.6)
• Clam Bed (group = 2.2.2.14)
• Benthic Macroalgae (subclass = 2.5.1)
• Seagrass Bed (group = 2.5.2.1) -- potentially folks would like this split into Z. marina and Z. japonica

I think it could be helpful to have a legend that shows when these different elements occur together, rather than picking one of the classes to show.