Are we are talking about the latest software changes and improvements to Civil 3D? There is a recent Autodesk Civil 3D 2023.2.2 Update that includes some useful performance improvements and better Autodesk Cloud behaviors with the Autodesk Desktop Connector 126.96.36.1992 Update. Today we are not here to discuss that type of feature.
We are here to talk about Civil 3D Features – Alignments, Profiles, Corridors and such. If you prefer - all of that stuff we see in the Civil 3D Toolspace. Technically speaking, these programming objects are called Features as they are collections of Objects that interact. That is Object-Oriented Programming (OOP) speak.
Whether we like it or not, the Civil 3D Features matter a lot to how we implement and employ Civil 3D in civil engineering and survey production environments. We certainly must implement Autodesk Civil 3D successfully. That means we need wrangle a set of functional Civil 3D Features into an implementation or Civil 3D Sandbox project that is separate from our actual project work.
Do you have a continuously improved Civil 3D Implementation Project?
Maybe this informative post will inspire some to do just that. The Framework for Civil 3D includes an implementation (aka Sandbox) project. By design all the Civil 3D resources listed below are included in the Framework.
This mission critical Civil 3D Implementation post remains a work in progress. The post has been updated since its original publication date.
Civil 3D Features - What Matters Most?
The Data centric and model-based nature of Civil 3D means that Civil 3D Features are more important than anything else. A Civil 3D Feature is where the civil engineering and survey data is stored; the method by which the Feature is displayed, annotated, and published; and where and how we create, manage, and edit the model’s data behind.
All the following 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.
- Civil 3D Features are Collectors of properties and Managers of the interactions.
For example: the Alignment is a Design Control Manager and not merely a supped-up polyline we employ only for horizontal control.
Unlike raw AutoCAD, the old school CAD Layer System is no longer the primary collector or Information Manager in Civil 3D.
If we miss that vital point, Civil 3D will always remain painful.
The Managed Dynamic Model
Features are (usually) contained in drawings. Survey Points are one exception. However, a Civil 3D project is not only a collection of XREFed (External Reference) drawings like a traditional CAD project or plan set.
The Civil 3D project is a managed collection of connected and/or disconnected DREF (Data References) Features and that may also include collections of XREFs and IREFs (Image References).
This current project state we call a Managed Dynamic Model.
If we consider a Managed Dynamic Model to be something static in a drawing, we miss a most important fact about Autodesk Civil 3D.
Civil 3D Project Management
The critical path task of Civil 3D project management is then about creating, editing, and managing these critical Features and their interactions. At this point in time, the Feature interactions (resolutions) occur inside drawings and/or within one of the Civil 3D Collector Features. Typical collectors include Point Groups, Surfaces, Site Parcels, Gradings, Alignments, and Corridors to name a few.
Civil 3D Users must perform the actual connection tasks and the internal project management work.
A Managed Dynamic Model must be a functional and daily reality for users.
The project management work effectively depends on people that understand and prioritize this project management work.
It is way too easy to lose our perspective and sense of priority inside a working project.
The Civil 3D Implementation Project
To effectively test Civil 3D project functionality, we need known Feature data to examine and test our Style tools and the processes (workflows) all the way to our final delivery endpoints.
A Civil 3D implementation project has a Feature centric structure often built around the major Collector Features employed in the project. Yes. That means there are types of projects and/or subprojects if you prefer.
The project structure must recognize Existing conditions, multiple potential Proposed design conditions, and submitted or published conditions.
It must be able to adapt to Managed Dynamic Model changes – changes of State.
The structure itself must contain and track data going in and published Feature data coming out by known methods users can see inside and outside of the software.
Both inside and outside of Civil 3D, the names of the many parts of the project structure are our best management tools.
Identify and Track Feature Limitations
All development and design work, including Civil 3D implementation, is a work in progress.
- The Civil 3D Features are not perfect.
Current Civil 3D Feature capabilities and limitations must be assessed.
- Do we study the known Feature limitations that may affect our work?
- Do we search out work-arounds before the limitations become a crisis?
- Do we reassess after new Releases, Updates, or other enhancements?
- Do our old expectations generate false limitations?
This final form of Assumption happens to the Civil 3D expert and novice alike.
Due to the object-oriented methodology in which Civil 3D is developed and maintained, our access to the Features and our ability to affect their output is very consistent. The Civil 3D Features and the Civil 3D object model does change, but how the Feature works and how we can get at them cannot be significantly changed without undermining the previous programming work.
We 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.
- Features don’t mind being objectified.
- All Features suffer from the worst form of Autism.
They try to swallow what we feed them like great white sharks.
- Features remorselessly reject what they do not understand
even if the data makes perfect sense to us.
- If we feed them in the wrong order or push them too quickly
Feature will reject us and that may wreck our day.
- Civil 3D Features don’t care much about their personal hygiene nor
how that reflects on us.
Civil 3D Feature Property Fundamentals
Civil 3D Feature property fundamentals are in every civil engineering and survey project’s critical path. Feature Properties define the Civil 3D data behind.
- 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.
- If yours is a larger organization, assign the learning and delivery tasks to different Civil 3D Feature mission specialists.
The subtle, identifiable, and nuanced differences between the two distinct sets of properties are vitally important to understand and communicate. Note that many Civil 3D updates and improvements make previously fixed on-create properties into unfixed and changeable properties.
Looks Don’t Matter to Features
All Civil 3D Feature representations and their annotations are abstracted to named Style and Label Style references.
Abstracted means for us that what Features and annotations look like are sets of properties collected separately and independently from the data behind.
There are Civil 3D Features that don’t separate perfectly into representation and annotations because they are representative Features anyway.
We hear the words, but we may misinterpret what this means to our implementation project strategy and tactics.
Our perception of Style and our immediate intent is to turn Style into what we 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 annotations appear.
We care, but the Features don’t behave that way at all.
Employed wisely, our applied AutoCAD CAD Standards skill can pay off there.
See the recently updated Civil 3D and The Elements of Style post and the entire Civil 3D Style Maintenance Handbook post series for the many details.
The Power of Names
The Civil 3D Feature Style and Civil 3D Feature Label Style separation says 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 Style and Feature. That Name, often taken in vain or for granted, is far more important than what it looks like or where the referenced CAD stuff goes now.
Did they tell us that in a Civil 3D class? Probably not. When we train people, everything we do is something to be thrown away. In real world projects, we must keep many things.
The Separations of Civil 3D Features
Our Civil 3D projects must store Features separately from the current applied Style definitions whenever and as much as possible. This is especially critical for quality controlled and checked (Done) Features that are referenced throughout a working project.
Preserve, clean, and protect the Civil 3D Feature data behind first.
We must often separate both Features to be published and their companion and dependent publishing Features from our Existing and Design Features.
These separations require new forms of workflow discipline we never expect to be important when we open the software and start our first project.
See the recent Civil 3D Reference Replacement and Tools post and videos.
The Drawing and Template Multiplicities
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 The Multiplicity of Civil 3D Drawing Types list, no matter what we call things, is bigger than we’d like.
How many Civil 3D templates do we need? One template will never work.
See The Multiplicity of Civil 3D Templates post.
How many Styles and Sets do we need? In practice this is potentially a staggering and overwhelming number. We don’t need all of them all at once. Process first. The Framework for Civil 3D supplies more than adequate 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. A Civil 3D Project Template 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 in here.
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 our daily project quality control and check loops do not happen in the Sheet Set context, then plan set deliverables become the crisis.
Civil 3D Model templates – these contain the Styles and Set tools we need to create, edit, maintain, and publish the Civil 3D 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.
Now we know more about what to look for and how to judge it. It is out there.
Register. Get access to more in-depth implementation, management, customization, video training, and documentation and help and for Autodesk Civil 3D.
How to Make Civil 3D Work for You
Get the Framework for AutoCAD Civil 3D