I intentionally employ the metaphor of the US Constitutional principal of the Separation of Powers to talk about how civil engineers and surveyors need to systematically manage to divide and conquer resources and more inside and around Civil 3D. The Arts of Separation help us all to employ the software successfully in production.
The principals of separation are, as they say, self-evident. The application inside and around Civil 3D is far from clear. The Separation of Powers analogy in brief…
Branches on the Tree of Liberty
From an executive viewpoint we want our 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 improved professional design practice.
Legislatively, the project and deliverable results are always a form of resolved human compromise. It is safe to say that the specifics of resolved is often subject to change without notice. In some cases, compromise occurs without our direct consent and/or against our current better judgement.
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 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 around Civil 3D matters to Civil 3D Users, Project Managers, and Principals.
The confusion arises because we attempt to depersonalize into a corporate trope (aka - management speak) what is deeply personal – our daily work. Personally and corporately, our work is balanced upon this three-legged stool of separation powers. Within the context of project work, every participant has executive, legislative, and judicial powers.
The issue isn’t whether we recognize that or not, but whether we proactively act and constructively behave to address the challenges. I purposefully do not employ the word stakeholder. All too often the term seems to marginalize the work itself.
Civil 3D is the Project
In the recent 10 Best Civil 3D Production Tips for 2020 post, I made these tongue in cheek statements in the Practice the Arts of the Separation of Powers section. 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. Control and governance 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 our 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 the Project context.
Every 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.
Yes, 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? There’s that tri-part syntax yet again. Funny how people often tend to want 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.
To briefly explain:
- Change the build properties of the included data of a surface then try to tell yourself that the newly resolved surface is the same surface.
- Is a collection of parcel segments a parcel? When those segments do not enclose an area, obviously not. Where and how are those unresolved parcel segments collected?
- Civil 3D doesn’t care about duplicate parcel segments or partial overlapping ones. You probably will care later when someone needs a published parcel report.
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 may certainly affect a Corridor model or Grading Feature 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 collect, resolve, and publish Civil 3D functionalities?
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 doesn’t police whether you pile a bunch of Civil 3D Features into a single drawing and design, QAQC, and publish that way.
Back in the day folks used to call this the Civil 3D Dynamic Model. Interactive Features that recognize and respond to changes in other Civil 3D Features are a powerful and useful thing. Note that the catch phrase fell out of vogue.
The reality is that in a project the dynamic interactions must become a Managed Dynamic Model or the project work tends to go to hell in a handbasket. Everyone owns the 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 newer Reference Template (TREF) capabilities in Civil 3D projects:
- Performance ramifications – it is easy to degrade production and publish drawing performance
- Design limitations – it is far too easy to kill off design optionality and/or reduce the flexibility to change in mismanaged reference structures
- Publication complexity – it is way too easy to 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 specialize around Civil 3D user personal preferences of structure and order. All of 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 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 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 primitive-based and not fundamentally Feature data-based.
We tend to want to ignore the realities of changes of State to the Civil 3D data behind. Identification of these State changes within our Civil 3D workflows are a mission critical tasks. Civil 3D users, Project Managers and Principals can and should have an understanding and say in that identification and the application rules.
State changes create Benchmarks which drive more managed changes and behaviors or they do not.
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.
One 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 execute 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 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 aspect of the Features in the Civil 3D 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 things throughout the Civil 3D interface.
Everywhere there are names. Name 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
The New Civil 3D Directions Posts
- The principals of good governance applies to our Civil 3D Projects and our people
- An ordered list of ordered lists assembled from an ordered structure of resources... seems to say it all
- A new look and direction for our old friend the Description Key Set
- The essential Key goals for better Civil 3D development and implemention
- The Hows, Whats, and Whys the matter for Civil 3D Project execution
- Why and How Styleless Data References make Civil 3D work better and reduce Upgrade and Update hassles
- Proactive and practical steps to take to make Civil 3D Upgrades and Updates easier