Are we are talking about the latest software changes and improvements to Autodesk Civil 3D today?
No. But there are always some recent product feature updates that come with benefits.
We are talking about Autodesk Civil 3D Features – Alignments, Profiles, Corridors and such. If you prefer, all of that Civil 3D Toolspace stuff. Technically speaking, these programming objects are called Features as they are collections of objects that interact with one another. It’s an object-oriented programming thing.
The Features matter a lot to how we implement and employ Civil 3D in civil engineering and survey production environments.
If we want to implement AutoCAD Civil 3D successfully we need to engineer the Features into an implementation project separate from our actual project work.
You do have an on-going and continuously-improved implementation project, don’t you? Maybe this informative and detailed post will inspire some to do just that. The Framework with Civil 3D includes an implementation project. All the Civil 3D resources listed below are included in the Framework.
This mission critical post is always a work in progress and has been updated since it's original publication date.
Civil 3D Features Matter Most
The Data centric and model-based nature of Civil 3D means that Civil 3D Features are more important than anything else. A Feature is where the data is stored; the method by which it is displayed and published; and where and how we create and edit the data model behind.
All the statements are true and inseparable in Civil 3D.
- Features matter most.
- Every Feature is a collection of components (objects).
- Features can and do interact with one another in a Dynamic Model.
- Many key Features are collectors and managers of the Feature interactions.
For example: the Alignment is really a Design Control Manager and not a supped-up polyline.
Unlike AutoCAD, your old school CAD Layers are no longer the primary collector or information manager in Civil 3D.
If you miss that point, Civil 3D will always be painful.
Features are (usually) contained in drawings. However, a Civil 3D project is not a collection of drawings like a CAD project. The Civil 3D project is more a managed collection of connected and/or disconnected Features. This current project state we call the Dynamic Model.
In other words, if we think of the Dynamic Model as something in a drawing, we have missed a most important fact.
The critical path task of Civil 3D project management is then about managing these critical Features and their interaction. At this point in time, the Feature interaction occurs inside drawings and/or within a one of the “collector” Features in a drawing.
Real-world, Civil 3D Users do the actual connection work. Therefore, a Managed Dynamic Model must be the real deal. Doing that depends on people understanding and always doing that management work first. It is too easy to lose this sense of priority and perspective inside a working project.
A Civil 3D implementation project has a Feature centric structure and the structure must adapt to Dynamic Model changes. It must contain and track data going in and published Feature data coming out by structural methods and patterns that users can see. To practically test that reality, we need known Feature data in the implementation project to examine our Style tools and the processes (workflows) all the way to our final delivery endpoints.
Identify and Track Feature Limitations
All development and design work, including Civil 3D implementation, is a work in progress.
- The Features are not perfect.
Current Civil 3D Feature capabilities and limitations must be assessed. - Are you learning the known Feature limitations that may affect your work?
- Are you searching out work-arounds before a limitation becomes a crisis?
- Do you reassess after new releases, updates, or productivity pack enhancements?
- Have CAD-based or old expectations generated some false limitations?
- That last form of Assumption happens to the Civil 3D expert and novice alike.
Due to the object-oriented methodology by which Civil 3D is developed and maintained our access to the Features and our ability to affect their output is very consistent. Features do change, but how the Feature works and how we can get at them cannot be significantly changed without undermining the previous programming work. You can bet and bear witness to that happens rarely. Programmers are people too.
Features are not People
We can love or hate them, but Civil 3D Features are not people.
- Features don’t care if they are understood.
They don’t mind being objectified. - All Features suffer from the worst form of Autism.
They try to swallow what you feed them like great white sharks. - They remorselessly reject what they don’t understand
even if the data makes perfect sense to you. - If you feed them in the wrong order or push them too quickly
they will reject you. That may wreck your day. - They don’t care much about their personal hygiene or
how that reflects on you.
Civil 3D Feature fundamentals are in every project’s critical path.
- Assign the learning and delivery task to different Feature mission specialists.
- Civil 3D training must include the care and feeding of each Feature.
- Almost all Features have properties that can only be set on creation.
- Every Feature has properties that can be changed later.
- Understanding the subtle and identifiable differences between
these two sets of properties are vitally important.
Looks Don’t Matter to Features
All Civil 3D Feature representations and the Label Style annotations are “abstracted” to named Style references. What Features look like are collections of Style properties collected separately and independently by name. There are Features that don’t appear to separate perfectly because they are representative Features anyway.
We hear those words but we may misinterpret what this means to our implementation project strategy and tactics.
Our CAD perception of Style and our immediate intent is to turn Style into what I want.
Isn’t that what Style is there for?
Yes and No.
Features don’t care about AutoCAD stuff like Layers, Colors, and specifically how the Features and their Label Style annotations appear.
You care, but the Features don’t at all.
Used wisely our applied AutoCAD skill can pay off there.
The Power of Names
The Feature Style separation means that we can redefine the displayed specifics (what it looks like, where the CAD stuff is assigned, etc.) anytime we want, if, and only if, we are very careful about the Names we use to identify both Style and Feature. That Name, often taken in vain or for granted, is far more important than what it looks like or where the CAD reference stuff goes now.
Did they tell you that in your Civil 3D training class? Probably not.
When we train people everything we do is something to be thrown away.
In real world projects, we must carefully store and manage those things.
Feature Separations and the Separation of Powers
Our projects must store Features separately from applied Style definitions whenever and as much as possible. This is especially critical for quality-controlled (Done) Features that are referenced throughout a working project.
Preserve, clean, and protect the Civil 3D Feature data behind first.
We must usually separate both Features to be published and their companion and dependent publishing Features from our Existing and Design Features too.
This requires new forms of workflow discipline we never expect to be important when we open the software and start our first Civil 3D project. See the link above for related posts on these topics.
A working project has create and edit drawings (model drawings), reference drawings, collector drawings, and multiple forms of publish drawings. The whole list of Civil 3D drawing types can be found here. The entire list, no matter what you call things, is bigger than we’d like.
How many Civil 3D Templates do we need? One Template will never work.
How many Styles and Sets do we need? In practice this is potentially a staggering and overwhelming number. You don’t need all of them all at once. Process first. The Framework for Civil 3D has the Style tools anyway.
The Implementation Project Definition
All the pieces of an implementation project are built into Civil 3D by the software’s own scope definition. Autodesk ships Autodesk Civil 3D with it. The supplied examples may be inadequate or bad from our perspective, but the parts and pieces are all there. Be wary of adding more. KISS.
The Civil 3D Project Template – this is the core working project structure, the container for your approved in-use resources, your backup and archival strategy, and ultimately your delivery method to the troops. It represents the current “approved” snapshot of our on-going implementation project. All the rest is in here. Many people miss the basic reality we can pre-build the core named Features and key file resources into Civil 3D Project Templates.
The Sheet Set Template and Sheet Templates – these define the published model output in Civil 3D. There is a folder structure, naming conventions, standard resources, and methods to hold that buried in here. If the daily project quality-control and check loops do not happen here, plan set deliverables become the crisis. Since there are always multiple deliverables, we must plan to manage them.
Civil 3D Model templates – these contain the Styles and Set tools we need to create, edit, maintain, and publish the model Features. A Civil 3D Template is said to be the Holy Grail of Civil 3D implementation. This is a deception. The good news - You can now avoid that work as much as possible.
Civil Engineers and Surveyors are smart people. Don’t reinvent the wheel. Build on known standards of your choosing. Build on the work of others. Go find that. You know more about what to look for and how to judge it. It is out there.
Get the Freedom to Make Civil 3D Work
Get the Framework for Civil 3D
Register. Get access to more in-depth implementation, management, customization, video training, and documentation and help and for Autodesk Civil 3D.