Intentionally, I employ the US Constitution’s analogy of the Separation of Powers to talk about how civil engineers and surveyors need to systematically manage to divide and conquer resources inside and outside Civil 3D. The perspective allows us to employ the software successfully in production.
The Principals of Separation are, as they say, self-evident. The practical application of the concepts inside and outside Civil 3D are far from clear.
Let’s discuss the Separation of Powers metaphor in brief…
Branches on the Tree of Liberty
The Executive viewpoint - We want our civil engineering and survey projects to proceed efficiently and sequentially via known and established workflows to a predictable and repeatable result. This allows us to assign tasks, accountabilities, and measure project performance to one degree or another. We require positive financial results, and we desire improved professional design practice.
The Legislative viewpoint - The project and deliverable results are always a form of resolved compromise. It is safe to say that the specifics resolved are often subject to change without notice. In some cases, compromise occurs without our direct consent and/or sometimes against our better judgement.
The Judicial viewpoint - Our project work is subject to the courts of judgement. Statute governance may resolve some unresolved compromises that can and do occur. Then again, those same statute decisions can wreck a mutually agreed upon and accepted project compromise completely. Statutes like historic statues can be, and are, pulled down and overturned all the time.
Beyond the gross political analogy itself, is another matter entirely to explain why the Arts of the Separation of Powers inside and outside Civil 3D matters to Civil 3D Users, Project Managers, and Principals.
The confusion arises in part because we attempt to depersonalize our daily work into handy corporate figures of speech. That daily work is always personal.
Personally, and corporately, our work is balanced upon this three-legged stool of separation powers. Within the context of project work, each participant has executive, legislative, and judicial powers.
The issue isn’t whether we recognize the conflict or not, but whether we proactively act and constructively behave in some practical ways to address the challenge.
Purposefully, I do not employ the often-abused word - stakeholder. People employ that term to marginalize the work itself.
All too often it appears that someone who holds a stake looks for an imaginary creature to blame and destroy.
Civil 3D is the Project
The following declaration raises the flag on the first degree of separation.
“Civil 3D isn’t about projects. Civil 3D is the Project. The Project is all about management. Good management practice isn’t about control but rather healthy governance.
Governance and control are not the same thing. Governance is about managing the mutual efforts of people with their willful consent. All the people at work on a civil engineering or survey project think and behave differently for good reasons.”
Civil 3D is a set of software tools. As frequent tool users, Civil 3D users, Project Managers, and Principals tend to think of the Project as a Civil 3D centric workspace. This perspective is a functional illusion of our own making.
Civil 3D has a few required structural elements and essential patterns of usage and yet Civil 3D is technically often more liberal than we are about that application in our personal or corporate Project contexts.
Each finished Project tells us what we did. We need to repetitively ask what we did not do to meet more people’s personal and corporate executive, legislative, and judicial project work needs. That continuous and repeated effort can produce better results in less man-hours.
We need to get a bit technical about Civil 3D itself.
Work By Data By Definition By Design
Model-based software is driven By Data By Definition and By Design. Hmmm?
Once again there’s that tri-part syntax.
Funny how we often tend quickly skip the definitions to a simplified phrase like Data Driven Design.
We assume Points are points, Surfaces are surfaces, and perhaps that Alignments are merely horizontal control mechanisms. A few days of production work inside Civil 3D speaks differently.
Civil 3D users can draw ACAD primitives and easily convert them into Civil 3D Features. The absence of definition awareness (and Civil 3D’s on create properties) can lead us to behave as though the Civil 3D Feature results are supped up ACAD primitives instead of separate containers of data that are managed and maintained.
Let’s explain by illustration:
- Change the Build properties for the included data of a surface then try to tell ourselves that the newly resolved surface is the same surface. Put another way - a TIN with only point data is not the same as a TIN with point data and the breakline data between point data.
- Civil 3D doesn’t care about duplicate parcel segments or partially overlapping parcel segments. We will care later when we label the parcel and when we need a published parcel report.
- Is every collection of parcel segments a parcel? No. If those segments do not enclose an area, obviously not. Where and how are those unresolved parcel segments collected in Civil 3D?
- Civil 3D is perfectly happy with non-connecting collections of segments in an Alignment. Are we?
By definition, all Civil 3D Features are collectors (resolvers) and therefore may become publishers of their data behind or not. A Surface that does not display can certainly affect a Corridor or Grading that targets it.
The nuanced application of Civil 3D Feature Data, Feature Definitions, and Design properties are the heart and essence of much intermediate and advanced Civil 3D skill.
The problem is our historic CAD design heuristics and workflows tend to disguise or even hide some of the potential benefits.
Do we rightly recognize, manage, and maintain the separations between the collect, resolve, and publish functionalities in Civil 3D?
The Managed Separation of the Civil 3D Data Behind
At the beating heart of model-based design is the core concept that an iteratively built model and the managed data behind that the model depends on will produce the published results we will require.
Civil 3D does not police whether we pile a bunch of Civil 3D Features into a single drawing and design, QAQC, and publish that way.
Back in the day the Autodesk folks used to call this the Civil 3D Dynamic Model. Interactive Civil 3D Features that recognize and respond to changes in other Civil 3D Features are a powerful and useful thing. The Dynamic Model catch phrase fell out of vogue.
The reality is that in a Civil 3D project the dynamic interactions must become a Managed Dynamic Model or our project work tends to go to hell in a handbasket. Every Civil 3D user owns that tee-shirt and that hat.
There are significant issues to not managing and employing clean and well-structured External Reference (XREF) structures, Data Reference (DREF) structures, and Reference Template (TREF) capabilities in Civil 3D projects.
For example, it is way too easy to:
- Performance ramifications – Degrade production and publish drawing performance
- Design limitations – Kill off design optionality and/or reduce the flexibility to change in poorly managed reference structures
- Publication complexity – Over complicate publication
For better or for worse, the daily and practical Managed Dynamic Model work falls to the Civil 3D user level. Therefore, the Managed Dynamic Model work too often tends to focus around Civil 3D user personal preferences of structure and order. That suffers from the immediate need to get things done in the short term.
We all tend to initially mash together the Civil 3D collect, resolve, and publish mechanisms. We tend to focus on the visuals and drawing representations and not the data behind that drives all of that. We are visual beings adrift in a sea of data.
The States of Change
The model building and publishing problem and the complexity of the output publishing processes can easily become a beast all by itself in these multi-process and muddied waters.
Our decades of previous CAD experience teach us to go back and focus our time on the details present in the CAD model specifics to solve the problem. That focus is necessary when the CAD software is CAD primitive-based and not fundamentally Feature data-based.
We tend to ignore or forget about the reality of Changes of State to the Civil 3D data behind. The identification of these Changes of State within our Civil 3D workflows is a mission critical task. Civil 3D users, Project Managers and Principals can and should have an understanding and say in that identification and the resultant applied rules.
Changes of State create Benchmarks which drive more managed changes and behaviors.
The more important State of the Union to address is not the end of the project but the daily and disciplined Managed Dynamic Model work.
The Managed Separation via the Power of Names
Civil 3D doesn’t police what we name much of anything in Civil 3D. Yet, our naming rules and conventions, Civil 3D name templates, and the consistency of the same across many project drawings and multiple types of projects are almost the only reliable standards management device we have inside the software.
A single software rarely defines the entire scope of our civil engineering design and survey project work. We must carefully consider, and we should remain adaptive to the ever-growing interoperability and collaboration contexts of the names we employ. Our preferences exist in a world of legislative compromise like it or not.
All the executive management tools available in Civil 3D are name dependent.
All AutoCAD users get the basics of the Power of Names. We depend on it. We use Layers. If you employ Layer States (and you should), we get this even more. The name of the Layer references a discrete set of properties that make stuff look this way not that way. The use of Layer States teaches us this is a current and transient State – something temporary and malleable. Something we therefore have the power to manage and change.
Named Civil 3D Styles and Label Styles employ (reference) the AutoCAD named parts to express themselves. Civil 3D Style tools look for and match the exact names that we’ve agreed to. Change the meaning and contents of the property definitions connected to those agreed names and you can change anything.
When we employ the practice of Style Management we abstract (make relative) the details of the visual representation from the Civil 3D data behind. This doesn’t happen by accident or in a vacuum.
Civil 3D is all about creating and managing the data behind.
Civil 3D manages how things look and how they behave By Style and in those managed Feature collections we discussed earlier.
It is way too easy to overlook that sneaky behavioral aspects of Civil 3D Features in the object model.
The Power of Names is large and complex reality in Civil 3D. The complexity is partly a numbers game. There are force multipliers at work. That is what the word power means. It is partly because of the behavioral aspects of Civil 3D Features and Style and the direct user interactions with those throughout the Civil 3D interface.
Everywhere there are names. Names are built in By Definition and By Design and unavoidable. The names help manage and maintain the data behind or thwart that effort. We plan, manage, and maintain the names in Civil 3D or they control and confine us.
We treat the names personally. We take the names personally.
The Joy of Repetition and the Language of Separation Anxiety
Our human brains are hard-wired to attach personalized meaning to symbols, names, and actions. Given time and repetitive experience, humans are pretty flexible about reorganizing those meanings. We do that a little bit all the time.
Our language changes, but unlike computers, human language always has an unavoidable emotional context.
We aren’t inclined to change that particularly when we attached the meanings to our personal sense of value and accomplishment. Reeducation can make us temporarily uncomfortable, confused and/or downright frustrated and angry. The adaptive process requires both separate and separation work.
We can acknowledge an adaptive reeducation process is going on. Hopefully, we can detach and separate our personal from our corporate and personal need to improve the project work.
Separate From the Pack
Get the Framework for Civil 3D Release 8