Primary Principles
Design is a small fraction of the overall Lifecycle.
The Asset is "permanent". It's phase/state changes. The Design/Proposed state is comparatively brief.
Owner Operators are the dog, we Designers are the tail.
That means our "traditional" method of classifying an asset (say, a drainage inlet) by its storage location (the file it is in or the level it is on) doesn't work. It doesn't work for BIM. It doesn't work for Digital Twins.
A major goal of the OpenRoads revolution was to build a platform that dovetails more closely or even integrates directly with Asset Management Systems.
Civil Features is the architectural foundation of Bentley's effort to make OpenRoads BIM-compliant and Digital Twin-ready in their Common Data Environment (CDE).
In data management terms, the Feature is the database entry and its Feature Definition is the "Primary Key". It is the Feature's most important property and it defines the Feature's data architecture.
Levels or layers (or symbology differences) were once primary (and sometime only) way to segregate data. It can still be done but in the BIM, Digital Twin, and OpenRoads framework, it is a result and not a cause, a capability - NOT a paradigm.
OpenRoads BIM and Digital Twin integration is based on the Feature and the Feature Definition.
Phase Shifting
A Best Practice in the GIS days was that the database record was the primary source of data, its 2D coordinates were a property and its symbology was another property.
Bentley's CDE is the DGN, and the 2D or 3D graphic contains the database record. Ideally, the symbology should be a single changeable data field. It works this way in many cases. You can change an element's Element Template and the symbology changes. This even works for many OpenRoads Features.
Changing a Drainage Inlets phase and symbology from Design to To-Be-Constructed to As-Built to Existing/Constructed should be a one or two field change.
OpenRoads Imperfect Implementation
Bentley almost implemented symbology properly with a single property for defining the display settings: Feature Definitions require a Feature Symbology (data structure: it points to multiple settings).
When creating a Feature and selecting a Feature Definition, the Feature displays according to the display settings as defined in the Feature Symbology. That's not bad.
Where the Implementation fails is that the Feature Symbology is not exposed - it can not be changed.
|
The workaround is that the exposed properties CAN be changed. The best available practice (since the Feature Symbology isn't available) is changing the [Element] Template. That will change the dependent properties (Levels, Colors, Cell, etc.). This currently works for all basic elements and some Feature Definitions, but doesn't work for utilities. It seems to have trouble with elements with 2D/3D dependent representations, especially where cells are involved. |
|
The Fix?
So currently (August 2024), changing the display properties of a Feature Definition natively is imperfect and the workarounds are either poor data management (having a separate Feature Definition for different phases) or a partial crash fest by changing the exposed symbology attributes.
I'd like to see Feature Symbology exposed as a property of the Feature. It's the purest fix from an architectural standpoint, but it's a significant architectural change. I do not see that happening.
What I expect to see - and I don't think it's an unreasonable ask, especially since it would make the breadth of OpenRoads Features consistent with how the platform works - is that Bentley fixes the code so that changing the exposed property Template works (instead of crashes). While not ideal, there are multiple workflows that will work just fine with this consistent platform-wide capability.
Alternatives
I can do some simple phase-based resymbolization using a State property and Display Rules. But the complexity ceiling on that is very low.
What Say You?
What is your preferred/ideal workflow if you could have one? Let me know: