It’s a fact, Jack. You invested money in the world’s most popular civil engineering and design software. You (or someone else) will have work hard to make the software run productively and publish your civil engineering design or survey work acceptably.
Every Civil 3D user and expert will tell you, “You need a Civil 3D template.”
They’re right - sort of. You'll really need more than one.
The supplied example Autodesk template files (.dwt) are just that – examples to show you that things are possible. A great many “things” are possible in Civil 3D. It is data-centric, model-based software.
As a dedicated content developer and continuous customizer of Civil 3D, I hope the following perspectives and tips help shorten the cycles and reduce the pain of customizing AutoCAD Civil 3D.
An earlier version of this post originally appeared in AUGI World.
AutoCAD Civil 3D was 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.
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 with a plan checker or two (or three or four) stuck in between.
As a professional developer, I prefer to call them “Plan Set Languages”. This helps focus the development to the publishing of Civil 3D data. Most people throw a fuzzy word around this complex mix of human perceptive and technical 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 simply must Google or Bing her.
Standards Documentation is Required
Pick A Standard and Manage By It
“We already have a CAD Standard.”
This may be the first and worst Civil 3D customization mistake any skilled AutoCAD user or organization can make. The odds are the CAD Standards you employed before do not take in account the data centric and model- based methods that Civil 3D employs. Simply put - Civil 3D is all about the "data". Then C3D manages how things look and behave by Style and in collections. Primitive based ACAD Standards, which only have rudimentary kinds of "style" and really no collections, often get in the way of this new collected way of doing things.
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 that CAD primitive stuff was to be SPECIFIC about all the details all the time.
The drawing we create and check things in becomes 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 its time saving and competitive advantages.
While the old CADD 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 process instead. Properly employed Civil 3D Feature data and Style make this possible.
Civil 3D Styles and Label Styles do employ the AutoCAD Layer, Textstyle, Block (style)references ACAD customizers are used to. The software is still called “AutoCAD” Civil 3D after all. Our AutoCAD customization skills DO still apply. BUT we must 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 “express” themselves. Style tools just look for and match the “right” names. Change the “meaning” and/or the property definitions 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”.
Such a namespace (in engineering speak) answers the question – in this context does “DI” means a “drop inlet”? The structure of a customization “namespace” for your Civil 3D references we’ll get to in a minute.
Are Description Keys a Namespace?
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.
Remember that wildcards do work in the RENAME command.
Whatever the madness you produce... your existing Civil 3D Styles and Label Styles will happily work exactly the same.
The components in the Civil3D Feature and Label Styles will go to your newly named layers. Since you didn’t change the property definitions of the Layers either – nothing changes.
This is not too exciting until you consider carefully about what this means. If you agree on the names, you can change almost anything.
Rename AutoCAD References
Follow a Script
Obviously as Civil 3D customizers we never want to do this rename work manually. Computers are faster, better, and more exact typists than us anyway. We commonly rely on AutoCAD Scripts generated from Microsoft Excel spreadsheets. (See the end of this post.)
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 really ever in the drawing per se. These occasional and more indirect references often fool us into thinking something else more mysterious (or at least inconsistent) is going on.
What Really Matters
Simple in concept AutoCAD Civil 3D Style is mind-boggling abstraction. Everything is designed and built to point at references. Once you start naming things you have committed to the specific "nature" and maintenance of the potential reference connections.
We can employ the abstraction of Style for our benefit.
In one sense AutoCAD Civil 3D Style doesn’t care about AutoCAD Layer standards, Block libraries, Textstyles, Colors, Plotstyles or really anything else AutoCAD. We need to recognize and think that way too. 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 and predictable results.
That Current word I 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 specific property references; and quickly produce a different result.
The Current method makes it easy to propagate success and mistake.
It becomes repetitively tedious to make fixes.
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 tested standards. In many respects, we employ the NCS, UDS (Uniform Drawing Standards), etc. in our Production Solution products because of the underlying How and Why for those published standards and their practically proven Rules.
Why reinvent the wheel? We want to build faster, high-performance vehicles.
The Standard Keys to Names
The NCS employs a hierarchical concept of Keys.
The Keys are structured "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. 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.
Styles and/or Sets of Style in C3D do the work.
This KEY CODE structured pattern produces a 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, your users don’t and shouldn’t care anyway.
Below are a few of the NCS “like” Keys we employ in our products. We employ them for both Layer and Block collections. They may even be employed in Civil 3D Style names when that’s appropriate. (See the end of the article.)
Some Standard Keys
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.
You can think of ALL the ACAD references in any Civil 3D template as just another Set.
Beyond AutoCAD
Now we’ve looped back to Civil 3D Style tools and substantively their names and what their property definition 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 “right” Style tool to use.
The text of the Style tool’s name is often all you get the deliver to the user.
Typically it’s a pick box list. You might get lucky and have the Style Viewer.
However, we all find out quickly that the Civil 3D Style Viewer cannot really represent everything a Style can do. Why? It doesn't have the example data.
Limitations On User Choice
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.
ASCII order determine how our named Style collections get organized. Therefore, our chosen rules for Names must appropriately sort the order as well.
Complex graphic Civil 3D Features like the Views have a lot more going on. “My Standard Profile View” doesn’t cut it except in a publishing template.
The Style names must be more informative and specific.
Does the Profile View include Grid lines or not?
We must recognize that the engineering data behind what we want to visualize is variable and the user will have specific needs to get work done.
Simply put...When you check a surface you need to see the data in different ways than when the result is published.
Choice of Style is more productive. It leads to better decision making capability.
Choice is not contrary to publishing standards unless you mix the two different goals in your head and that infects your customization effort.
That mixture of goals is way too easy to do.
Production is Never Publication
When we open the Alignment Label Style collection in the Civil 3D Toolspace and/or start to assemble Sets of Label Styles, we see any hope of name simplicity for Label Styles disappears in a flash.
The vast 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 benefits.
Label Styles always have a geometric framework to them. It’s about “readability” and meaning. 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 Style upgrade stability.
There’s a NASTY recurring 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 work.
People will make things to get the job done.
Do you fight this built-in human creativity or enable it?
Our published The Simple Style Rules anyone can learn. They work.
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 two fundamental namespaces:
One for the top-end Styles and one for the backend ACAD references.
In production projects, we need a third namespace for how we name the Features, but that’s another story.
This client and this project demand these CAD Standards specifics. Another client and project demand something different. Even if you don’t believe you regularly face that common problem, you still have to improve your internal production templates themselves.
Kindly enough the solution process to overcome both challenges is exactly the same.
Work the Same
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 your 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.
“Change that manhole block to look like this manhole block.”
Your that must be specific.
Publish On Demand
Publish on demand capability is a productivity and competitive advantage, but it takes user and organizational repetitions to develop and practice these skills. It's about simultaneously doing managed process development while you do work.
If we must endlessly customize AutoCAD Civil 3D,
we should reap the benefits.
Here’s a link to the website page to download: the Standard Keys for the NCS like AutoCAD reference namespace and the Jumps Standards which include the detailed and documented Style namespace.
Excel Cell Formula Script Example for Rename
Here’s the pseudo code for a typical formula based Layer Rename cell. It creates a series of quote wrapped strings when a column of such cells is copied and pasted to an ASCII text file. The extra start and end quotes character can be easily removed in your text editor.
LAYER&CHAR(13)&"S"&CHAR(13)&(OldLayer)&CHAR(13)&"R"&CHAR(13)&(NewLayer)&CHAR(13)&(NewLayer)&CHAR(13)&"C"&CHAR(13)&(Color)&CHAR(13)&CHAR(13)&"LW"&CHAR(13)&(Lineweight)&CHAR(13)&CHAR(13)&"PS"&CHAR(13)&(Plotstyle)&CHAR(13)&CHAR(13)&"D"&CHAR(13)&(Description)&CHAR(13)&(NewLayer)&CHAR(13)