Your organization or firm invested money in the world’s most popular civil engineering and design software – Civil 3D. You (or someone else) will have work hard to make the Autodesk Civil 3D software run productively and publish your civil engineering design or survey work acceptably.
Every Civil 3D expert and most experienced Civil 3D users will tell you, “You need a Civil 3D template.”
They’re right - sort of. You need more than one Civil 3D template. The supplied example Autodesk template files (.dwt) are just that – examples to show you that things are possible in Civil 3D. A great many things are possible in Civil 3D. It is a data-centric, model-based software.
More recent template technology additions like Reference Templates, available in Civil 3D 2017+ can potentially create game changing advances to your production workflows. Autodesk will continue to invest in Reference Template code because it really matters. Is a Reference Template a template? Probably not. See the bottom of the post for links to learn about Reference Templates in Civil 3D.
Civil 3D ships with multiple kinds of other different template examples. While not the subject of this post, none of these other templates should be ignored and overlooked. Some are more powerful than those templates most people talk about. See the Civil 3D Project Template post and video series for example.
As a dedicated content developer and pretty much continuous customizer of Civil 3D, I hope the following perspectives and tips help shorten your own development cycles and reduce the pain of customizing the software. Earlier versions of this post appeared in AUGI World and other places.
Civil 3D is constructed from the ground up to disconnect the survey and engineering data from how that mission critical data is represented.
With Liberty Comes Responsibility
As far as Autodesk is concerned, what you want the many Civil 3D things to look like and how the Civil 3D data is to be annotated is totally up to you. Wait a minute. That’s not really true is it? Plan sets are published in arcane symbolic graphic languages designed to faithfully convey the design intent to someone who must build it. Actually, there is a plan checker or two (or three or four) stuck in between.
I prefer to call these symbolic and graphic representations “Plan Set Languages”. A Plan Set Language is specific to a professional design discipline and more specifically to the trades that do the actual construction. The phrase, Plan Set Language, helps us to focus on the purpose and intent for our development of the publishing of Civil 3D data. People throw a fuzzy word around this complex mix of human perceptive agendas and call that CAD Standards.
“The wonderful thing about standards is there are so many of them.” – Grace Hooper el al
If you don’t know who Grace Hooper was…you should.
Pick A Standard and Manage By It
“We already have a CAD Standard”.
This illusion may be the first and worst Civil 3D customization mistake any skilled AutoCAD user or organization can make. Don’t feel bad. Almost everyone does it. Many people still do it. You can make it work. Do you really want to?
The odds are the CAD Standards you employed historically do not take in account the data centric and model- based methods and workflows that Civil 3D employs. Simply put - Civil 3D manages how things look and behave by Style. Primitive-based ACAD Standards may get in the way. There can certainly confuse the mission critical project issues that Civil 3D production use presents to us.
Older CAD Standards by definition must be focused on CAD primitive publishing specifics: Layer, Textstyle (height), Block graphics standards, etc. In raw AutoCAD and AutoCAD based drafting and design software the only way to manage all the CAD primitive stuff was to be specific about all the details all the time.
The drawing we create and check things in is the drawing we publish.
If you publish work out of quality control or design drawings in Civil 3D, this is a sign you may be missing some of Civil 3D’s time saving production advantages.
While the old school CAD process works, it requires a lot of man-hours dedicated to maintaining and checking the details. Clearly, one of Civil 3D’s critical design development goals is to rid organizations and Civil 3D users of this expensive man-hour burden and cost. The idea here is to put the man-hours into the iterative engineering processes instead.
The Civil 3D Feature data behind and the abstraction of properties to Style make this miracle possible. To be clear, the Civil 3D Features are all those things we see in the Civil 3D Toolspace – Surfaces, Alignments, Profiles, etc.
Civil 3D Styles and Label Styles do reference the AutoCAD Layer, Textstyle, Block references that ACAD customizers are used to. The software is often still referred to as AutoCAD Civil 3D after all. Our AutoCAD customization skills still apply. However, we must all too often apply them differently and much more systematically. Here’s why…
How You Name It - The Most Critical Standard
Civil 3D Styles and Label Styles employ (reference) the AutoCAD named parts to represent themselves. Style tools just look for and match the assigned names. Change the meaning or assignment and/or definition of the names and you can change anything. We call this fundamental property and benefit of object oriented programming the Power of Names.
In programming speak this concept and practical reality is called a namespace. A namespace acknowledges the necessity of unique names. Such a namespace in engineering speak answers the question – in the Survey code context does “DI” means a “drop inlet”? The structure of a customization namespace for Civil 3D references we’ll get to in a minute.
To See How the Power of Names Works…
Go ahead make a drawing from your current Civil 3D template. Toss in some Civil 3D data by data reference from any project. Use the Rename command on any of the old AutoCAD style collections – Try Layers. Rename like crazy. Your existing Civil 3D Styles and Label Styles will happily work exactly the same. The components in the Civil 3D Feature and Label Styles will go to your renamed layers. Since you didn’t change the properties of the Layers either – nothing changes.
It’s not too exciting until you think about what the process demonstrates.
Follow a Script
Obviously as customizers, we never want to do this sort of work manually unless we are a glutton for punishment. Computers are faster, better, and more exact typists than we are anyway. We commonly rely on AutoCAD Scripts generated from Microsoft Excel spreadsheets. In the Framework, we call them Spreadsheet Tools.
There are a couple of key collections in the object model that Civil 3D walls off from this form of potentially destructive user madness. Object Properties in Drawing Settings and a few things like Figure Prefix Dbs values that are not ever in the drawing per se.
What Really Matters
Civil 3D Style is mind-boggling abstraction. Everything is designed and built to point at references. We can employ the Style abstraction for our benefit via a managed system or be overwhelmed by seemingly ever present sets of exceptions.
In one sense Civil 3D Style doesn’t care about Layer standards, Block libraries, Textstyles, Colors, Plotstyles or really anything else AutoCAD unless you force Civil 3D to do this in your Civil 3D Styles. From our perspective all the Civil 3D Styles care about are the arbitrary and exact names they currently reference.
The Civil 3D customizer’s dilemma: Keep book on the exact names. There are a lot of names to keep track of. You must have a plan. You must have rules. You must employ the same processes consistently in the same order to get quality assured results.
That Current word used above is a wonderfully relative term for the customizer.
Build a set of Styles; extract them to another drawing; rename and/or redefine the references; and quickly produce a new, different, and useful result.
The current method makes it easy to propagate both success and mistake.
The current method when applied to make fixes is painfully repetitive and tedious.
As innovative content developers for Civil 3D we chose to employ the National CAD Standard (NCS) as our fundamental Name standard. Not because we like the NCS, but because of all the hard won experience expressed in these project-tested standards. In many respects, we employ the NCS, UDS (Uniform Drawing Standards), etc. in our Framework products because of the underlying How and Why for those standards and their practical published Rules.
Why reinvent the wheel? We want to you to be able to build better, faster, high-performance vehicles. In any case, the NCS rules are remarkably flexible, robust, and adaptive simply because of how they came about.
The Standard Keys to Names
The NCS employs a hierarchical concept of Keys in a pattern. There are Major Keys, Minor Keys, etc. that have order, precedence, and an interpreted meaning. The NCS Layer standard employs the Key-based rules to produce defined meanings to Layers.
The NCS 6.0 pattern includes the concept of agreed to and regularized Major and Minor Key couplets. This is easy to overlook unless you look at the scope of all the layers across all the official NCS disciplines. Why the couplets? In practice and plan set everyone wants their task discipline Key to be a Major Key. In real world projects that won’t work. Major and Minor Key couplets are a functional compromise.
You can, in practice, employ the same Layer Keys to be as generic or a granularly specific about where the published results go. All the annotation can go to one Layer or many different Layers for example. Inside Civil 3D assigned Styles and/or Sets do the work.
This coded structure of Keys produces the flexible and structured namespace we referred to earlier. It’s a namespace that both the software can employ and is relatively easy of us dumb-bunny humans to learn to decode when we must. Most of the time, the Civil 3D users don’t and shouldn’t care anyway.
We publish the NCS Key Lists in multiple NCS versions as an Open Source resource. See the bottom of this post.
The customizing key point is that the meanings of these specific Keys can be translated into any other set (or sets) of different Keys. The Key changes can be systematically applied to whatever AutoCAD reference tables and resources we require.
The results of any changes will float uphill to the named Civil 3D Styles we choose to employ. That means we can think of all the many ACAD references in a template and a group of Civil 3D resources as a Set – a named collection of collections.
Now we’ve looped back to Civil 3D Style tools and substantively their names and what their parts refer to. Welcome to the circular and iterative world that is customizing and employing Civil 3D.
Aside from the requisite customization skills and experience to build Style tools, our practical biggest customization issues are frankly Civil 3D human interface issues.
No matter how you cut it you have a very limited amount of text space to help users decide on the appropriate Style tool to use for the task at hand. The text of the Style tool’s name is all you get the deliver to the user. Typically, the name is in a restricted pick box list. You might get lucky and have the Style Viewer. But even the Style Viewer cannot represent everything a Style or a Label Style can do.
What we call the Feature Styles (the Civil 3D Feature’s graphics) require that our Style names explain in simple readable human terms what the tool does. For example a Surface style like: Contours 1-5 Proposed. For the common and most understood Features this makes some sense. We must remember that the default ASCII character sort order rules how named Styles organize themselves in the interface lists. The alphanumeric order of our Names will help sort or hinder that out for our Civil 3D users.
Complex graphic Civil 3D Features like Views have a lot more going on. My Standard Profile View doesn’t cut it as a name except perhaps in a specialized publishing template. The Style names must be more informative and specific. Does the Profile View Style name include Grid lines or not?
We must recognize that the engineering data behind that we want to visualize is variable and the user will have specific needs to get work done. When you quality control check a surface, you need to see the data in a different way than how that same surface is published.
Choice of Style is more productive. Style Choice is not contrary to publishing standards unless you mix the two goals.
Manage the Label Style Madness
When we open the Alignment Label Style collection and/or start to assemble Sets of Label Styles we see any hope of name simplicity for Label Styles disappears in a flash.
The majority of Styles are annotative. There are a lot of forms and specific types of them. Label Style Type matters.
The smart customizer employs the Label Style Default (LSD) hierarchy expressed in the Toolspace>>Settings tab or ignores it and misses the powerful benefits of LSD.
Label Styles often must have a geometric framework to them. It’s about human readability and our brain’s ability to create meaning from spatial relationships. Whether this label goes up or down or attaches here and not there is critical to annotative clarity.
The graphic structure of many data rich Label Styles also fundamentally matters to the Label Style’s upgrade stability over Updates and new Releases. The Civil 3D object model does change. There’s a maintenance cost to pay if you refuse to employ consistent geometric structures in Label Styles.
Can users see the right data and at the right time? Will the user employ a General, Alignment, Parcel, or Figure Line and Curve label? How do they see the difference in a simple list? It is easy miss how “on-the-fly” annotative information negatively or positively effects design time decision making and quality control. People will make things to get the job done. Do you fight it or enable it? There are Simple Style Rules anyone can and should learn.
A Civil 3D Style naming convention must be: human readable, create order in the interface, and therefore include a rule based, an easy to learn code system that expresses quickly the critical details.
To customize we need multiple namespaces: One for the top-end Styles and one for the backend ACAD references. In production projects, we need a third critical-path based namespace for how we name the Features, but that’s another story.
To Work and Publish
This client and this project demand these CAD Standards specifics. Another client and another project demand something different. Even if you don’t believe you regularly face that common problem, you still have to improve the internal production templates themselves.
In the project-based, production world we work in, Civil 3D users and supervisory staff can always work with the familiar and publish what is demanded in a customized publishing template. The two pronged template approach has the added benefit of potentially quantifying the costs and real return on investment for the customization itself.
In practical terms, we can change the expressed graphics - the Plan Set Language (CAD Standards) with managed intern level staff. Even non-CAD people can see and identify graphic difference. Only basic AutoCAD and spreadsheets skills required for much of the work if you have a Naming plan and consistent rules.
“Change that manhole block to look like this manhole block.”
Your that must be specific.
Publish on demand capability is a productivity and competitive advantage. Publish on demand capability takes repetitions to develop and practice the necessary Civil 3D user skills and workflows. Some of these seem counter-intuitive or appear to require unnecessary work. The key is whether the work pays off or not.
If we must endlessly customize Civil 3D, we should reap the benefits.
Here’s a link to download the Standard Keys for the AutoCAD reference namespace.
Here’s a link to the Framework Standards documentation which includes the detailed and documented Style namespace.
Register on the website and gain access to organized documentation and help for all the topics introduced in this post.
Release the Power Beyond the Code
Get the Framework for Civil 3D Release 8
Back to the Civil 3D Fundamentals Posts