The Archives link lists all posts...

Civil 3D Features Matter Most

Tags feature, implementation, management, development, customization


Are we are talking about the latest software changes and improvements to AutoCAD Civil 3D today?
No. But there are always some recent product feature updates that come with benefits.

We are talking about AutoCAD 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. 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.

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 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 users can see. To test 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 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 a work-around before the limitation becomes a crisis?
  • Do you reassess after new releases, service packs, 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 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 and that may wreck your day.
  • They don’t care much about their personal hygiene or
    how that reflects on you.

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.
  • 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 annotations are “abstracted” to named Style references. What Features look like are sets of properties collected separately and independently. There are Features that don’t separate perfectly 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 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 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 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 CAD stuff goes now.

Did they tell you that in your 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 some things.

Feature Separations

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 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 project.

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 AutoCAD 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 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 the daily project quality control and check loops do not happen here, 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 model Features. The 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 Framework for AutoCAD Civil 3D

Register. Get access to more in-depth implementation, management, customization, video training, and documentation and help and for AutoCAD Civil 3D.