Customize Correctly
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 the engineering design or survey work acceptably.
Every AutoCAD® Civil 3D® user will tell you: “You need a Civil 3D template.”
They’re right, sort of. You 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 a 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 the software.
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, 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 agendas and call that “CAD Standards.”
“The wonderful thing about standards is there are so many of them.” – Grace Hopper, et al.
Figure 1: 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 manages how things look and behave by Style. Primitive-based AutoCAD® standards may get in the way.
Older “CAD” standards by definition must be focused on CAD primitive publishing specifics: layer, textstyle (height), block graphics standards, and so on. 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 its time saving 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. Civil 3D Feature data and Style make this possible.
Civil 3D styles and label styles do employ the AutoCAD layer, textstyle, block references AutoCAD customizers are used to. The software is still called “AutoCAD” Civil 3D, after all. Our AutoCAD customization skills still apply. But we must apply them differently and much more systematically. Here’s why…
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 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.”
Figure 2: Are description keys a namespace?
Such a namespace in engineering speak answers the question: “in this context, does “DI” means a “drop inlet?” In a minute, we’ll get to the structure of a customization “namespace” for Civil 3D AutoCAD references.
The Power of Names
Go ahead and 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 Civil3D Feature and Label Styles will go to your renamed layers. Because you didn’t change the properties of the layers either, nothing changes. It’s not too exciting until you think about what it means.
Figure 3: Rename the AutoCAD reference names
Follow a Script
Obviously, as customizers we never want to do this sort of work manually. Computers are faster, better, and more exact typists than we are. We commonly rely on AutoCAD scripts generated from Microsoft Excel spreadsheets. (See the end of the article.)
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
AutoCAD Civil 3D style is mind-boggling abstraction. Everything is designed and built to point at references. We can employ style abstraction 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. 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 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 different result. The Current method makes it easy to propagate success and mistake. It makes it repetitively tedious to make fixes.
No Can Stop
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 standards and their practical published Rules.
We want to build faster, high-performance vehicles. Why reinvent the wheel when we can improve on it?
Standard Keys to Names
The NCS employs a hierarchical concept of Keys. 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 do the work.
This KEY CODE structure produces a flexible and structured “namespace” we referred to earlier. It’s a namespace that both the software can employ and is relatively easy for us dumb-bunny humans to learn to decode when we must. Most of the time, the 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 and even the structure of libraries. They may even be employed in Civil 3D style names when that’s appropriate. (See the end of the article.)
Figure 4: 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. Think of all the AutoCAD references in a template as a Set.
Beyond AutoCAD
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 “right” style tool to use. The text of the style tool’s name is all you get to deliver to the user.
Typically it’s a pick box list.
You might get lucky and have the Style Viewer, but that Viewer cannot represent everything a style can do.
Figure 5: The limitations of user style choice
Feature Styles Names
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 rules how named Styles organize. Names must sort that out.
Complex graphic features such as 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. When you check a surface you need to see the data in different ways than when the result is published.
Choice of style is productive. Choice is not contrary to publishing standards unless you mix the two.
Label Style Name Factors
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 benefits.
Label styles often must 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’s upgrade stability. There’s a maintenance cost to pay if you refuse to employ consistent geometric structures in label styles.
Custom Usage
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 to 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? The Simple Style Rules anyone can learn.
The Civil 3D Namespaces
A Civil 3D style naming convention must be: human readable, create order in the interface, and therefore include a rule-based, easy-to-learn code system that expresses quickly the critical details.
To customize we need two namespaces: One for the top-end styles and one for the back-end AutoCAD 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 the internal production templates themselves. The method and process aren’t different.
In our project-based, production world, 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 project template approach has the added benefit of potentially quantifying the costs and real return on investment for the customization itself.
Customize to Publish On Demand
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 basic spreadsheets skills are 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 capability is a productivity and competitive advantage, but it takes repetitions to develop and practice the skills.
We must endlessly customize Civil 3D—reap the benefits.
Civil 3D Name Resources
The Standard Keys: the NCS like AutoCAD reference namespace. The Jump Standards: includes the detailed and documented style namespace. Find them at: www.cadpilot.com/resources.aspx
Excel Cell Formula Script Example
Here’s the pseudo code for a typical formula-based layer script that makes a layer table with all the details filled in from a cell. It creates a series of quote wrapped strings when a column of such cells is copied and pasted to an ASCII text file.
<LayerCommand>&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)
