Civil 3D bloggers often tend to focus on Civil 3D tactics rather than strategies. Civil 3D is a big and complex beast, so that is understandable. Here I try to strike a balance of the obligatory tactical detail and the loftier strategy issues that CAD Managers, advanced Civil 3D users, and customizers of Civil 3D must cope with. Like all the rest of you in Civil 3D Land, I continue to fail forward.
Someone complained to me that my recent series of posts on Civil 3D Project Start Up was too detailed. The posts missed the essential Civil 3D workflow basics he needed to communicate to new users and to his supervisors who did not use the software. This begs the all too familiar marital question…
Honey? Do You Need to Ask for Directions?
The fact that continuously improved Civil 3D Project Templates might replace the need to walk all of his new users through all the nitty gritty sequential steps to get to work somehow gets lost in the shuffle. After a longer chat, we discover he really wants a Civil 3D start-up checklist. I told him how to get to New York. He just wants to know how to book a flight. My tactical details confuse the strategic point. My bad.
It Pays To Be Prepared
The Civil 3D Managed Dynamic Model means that if you plan ahead carefully you can set a lot of the Data Shortcut (Reference) connections up in advance using simple placeholder Features in your Civil 3D Project Templates. Later you can replace these named connections (aka files) with more detailed or complete ones. See the aforementioned Data Reference videos and posts.
In other words, you can use basic or simple Features to do the initial Dynamic Model building up front and then work on improving the Feature details as the project moves along. As the details become more important to you, you can work on improving the published presentations too.
We need to remember that Civil 3D is very adept at adding unnecessary complexity into our design with little to no effort.
We need the corporate and user discipline to constrain this in a managed way.
The Planned and Managed Project
We want a Planned and Managed Project concept in place to do this. Both where you store the Features and what you Name the Features you are going to employ is important. The Framework for Civil 3D’s sample projects employ NCS and UDS compliant storage folders centered around specific key Civil 3D Features to emphasize the Feature centric principals that apply.
What you name the folders and the files is up to you. However, the project folder structure should recognize how Civil 3D functions where that is appropriate. There are still significant file-based reference limitations to too many things in Civil 3D. Most of those center around data Import issues into the specific Civil 3D Features themselves. For example: XML and/or FBK imports to name a couple of obvious ones.
Civil 3D Root Collectors
Some particular Civil 3D Features are Root Collectors. They matter all the time to one level or another. Obviously, Surfaces, Parcels, and Corridors come to mind.
For Corridors and their output tools for Plan and Profile sheets and/or Pages of Sections the primary collector is the Alignment. What I like to call the Design Control Manager for Civil 3D. For example: Section Line Groups are collected in the Toolspace under a Named Alignment. We can't move the Section Line Groups around so...
Do You have an Alignment Naming Plan?
Civil 3D uses a lot of alignments. Without an Alignment Naming Plan and the appropriate settings for the child Naming Templates you are going to get confused as the number of alignments and various related children explode in a project. When we start talking about Feature Line based Corridor Baselines the naming conventions can be even more mission critical.
We discover that managing our own self-induced chaos quickly becomes man-hour expensive if not problematic. Got my t-shirt.
In the Framework’s sample projects, we employ a basic Alignment naming scheme based on a grid of potential project wide alignments and the primary direction of the alignment itself. You can open the core Alignment data reference drawing to see the Project's alignment naming scheme at work.
The Framework’s Project alignment naming method isn't a law. It's just a suggestion based on successful implementations. The type of project work you face does make a difference. Five miles of freeway reconstruction is not an airport taxiway project nor is that anything like a new subdivision. Or is it?
Aside from a familiar street name what are the critical design parameters of an Alignment of a particular type?
In any case we need Feature Naming Rules. We need to follow them.
Separate the Key Feature References
The fact that the project Alignments and their key design Profile Features are NOT stored in the drawings used to generate other Feature Collectors like Corridors, published Profile Views, and design Features like Intersections is also mission critical.
The fact that these key project Civil 3D Features are stored without Style in the project is important. The need for NoStyles (style-less) Data Shortcut drawings is another topic I've covered before and won't belabor here.
Separating key Features out in the project in this fashion does allow you to REPLACE the Civil 3D Features as things change over the course of the project. The added benefit is your projects also become significantly easier to upgrade. Awesome.
When you do the Feature replacement is a formal quality control benchmark - a change of drawing State that you need to think about and establish. Put another way, our design remains as dynamic as is practical and yet the decisions do get made.
Build Power from the Civil 3D Data Behind
Get the Framework for Civil 3D
How to execute the practical steps.