Feature Styles, Label Styles, and Sets are separate and independent from the Feature Data. This good news. How we want to express or represent stuff in AutoCAD Civil 3D is almost without limit. The bad news is we forget and deal with Civil 3D style like it was a fancy version of old school CAD stuff. We’re human and we are visual. To see it is to believe it.
We see the aspen trees or maybe an aspen grove. We don’t recognize the forest may be one really big individual plant.
Civil 3D Feature and Style Truth
The built in model/representation separation inside AutoCAD Civil 3D 2013 means that model-based Style and all the annotation is ALWAYS temporary.
In Civil 3D production environments then Civil 3D user Style Changing skill is fundamentally more important and more critical to our successful AutoCAD Civil 3D implementation and project workflow reconstruction than Style editing detail geekdom.
Individual editing or “tweaking” a Civil 3D style in a production drawing is the ENEMY of consistency and eventually good quality control (QC) process and the data validation that better, faster, and more representative models require.
We need information. We need intelligent information even more. We need to be civil about it.
Is the Feature Data What We Publish?
The Civil 3D Surface Feature (something we all KNOW well) is a case in point. This beast is a container (or a collector) of a bunch of kinds of data (that are actually only TWO kinds of surface data), a group of specific Build properties (how and what data is processed), and the resultant surface model results - the TIN.
Typically our “Publish” or “Deliverable” Styles are NOT all that effective quality assurance (QA) and quality control Styles. They express or dumb down for others a bunch of other work. A “1 and 10 contours” Surface style works fine, but it misses the point of the process work that must get done. It’s a goal then. The specific style representation is not necessarily the best, fastest, and effective way to get from A to B.
You can find webinars and recordings about the Civil 3D specifics, if you follow the links. We're visual and it makes more sense...
Focus on the Purpose BEFORE the Detail
If we’re going to build and employ useful QA styles for surfaces we have three distinct kinds to deal with. Why three and not ten? Simply put - what the feature collects we have to validate at some point or suffer the consequences of assumption or the resultant poorly informed design choices that might result.
Here are the three:
- Analysis of the incoming Data whether it’s existing point and breakline data or finished versions of the same. We definitely need to check this stuff from other Civil 3D Features. We need Styles to help us visualize both the good and the bad.
- Evaluate both the In-Process and final Processed Results. Surfaces like almost all Civil 3D Features (definitely all the collector Features) perform algorithmic processes on what we input. Build operations and build order both can make all the difference. We can employ styles as visual triggers to help see what’s really going on. We have to have them and employ them in the same consistent fashion of course.
- Publish Finished Product Deliverable. Most of the time we’re also going to have to produce representations of the surface model for others to validate the decisions we’ve made. That’s going to require different styles as well. PDF or DWF output is simply fundamentally different than what may be required in a digital deliverable that may end up in a city base map.
Visualize in 4D
Now you understand why I think Quality Assurance Styles are the Most Important styles. I refer to this as “Visualize in 4D”.
These styles are employed ritually in time inside your standard Method and Practice– what people call Civil 3D workflow.
Users always bother to look. Your workflow guarantees it happens more than once by different people or you suffer the consequences. If you basically work alone, you have to be even more paranoid about this, but then you probably know that experientially already.
Good QA styles and workflow help reduce the source Data complexity. This involves BOTH employing styles and changing the build properties in systematic ways to validate what’s in there. Features like surfaces can have a huge amount of disparate data – both the little fine grained stuff and the large scale big stuff matter.
Styles that help users SEE these differences are pretty useful. That’s why Civil 3D has all those Range based Analysis tools hooked up to the Surface’s components.
Mind Games and Groupthink
If you can’t think of a reason to employ a specific form of Surface Analysis, that should be a hint that you may be enforcing a form of systemic blindness into your work. It doesn’t matter because you choose to ignore it. This human mind trick is far more common than any of us like to admit. The human tricks come in a wide variety of flavors and variations.
Here’s one of my favorites: