Your organization or firm invests money in the world’s most popular civil engineering and design software – Autodesk Civil 3D. You (or someone else) works hard to make the Civil 3D software run productively and publish your civil engineering design or survey work acceptably. Odds are you have something that works. Can we do better? Can we improve that?
Every Civil 3D expert and most experienced Civil 3D users will tell you,
“You Need a Civil 3D Template”
They’re right - sort of. A Civil 3D template appears to be like the Holy Grail, but really is not.
We need more than one Civil 3D template too.
Did they remind you that there are many forms of templates in Civil 3D?
See The Multiplicity of Civil 3D Templates and the companion The Multiplicity of Civil 3D Drawing Types posts.
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 a great example.
Register, become a site Member, and discover more about Civil 3D Templates, forms of Civil 3D Template construction and maintenance, and the Civil 3D Templates implementation in detail.
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 and published.
Liberty Begets Governance and Responsibility
Let me point out that Freedom, Liberty, and Right are very different words that many folks always love to confuse and conflate.
Like the song says, that Freedom often appears to mean Nothing Left to Lose. That creeping suspicion should confirm for us all the significant and practical matters of Liberty that are at hand.
Liberty means the will, ability, and self-discipline to govern yourself and under certain conditions govern the actions of others.
Those conditions are Rights (The Freedoms of) that mitigate and constrain our personal and corporate Liberty to govern whether we like that or not. This simply explains why these Rights are unalienable in principal but more importantly - in practice.
Liberty is derived from our practical, mutual, and agreed self-interest.
Liberty is not derived from Rights. Liberty is constrained by Rights.
Liberty and Civil 3D
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. We are free to do whatever we like.
Wait a minute. That’s not really true is it?
Plan set deliverables are published in arcane symbolic graphic languages designed to faithfully convey the design intent to someone who must build it. These days 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 perform 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 Civil 3D 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. The more important question is, “Do you really want to?”
The odds are the CAD Standards you historically employed 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 will get in the way. These can certainly confuse the mission critical project issues and different workflows 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. I have to point out - this is an illusion and problem of our own making.
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 biggest timesaving, production advantages.
The old school CAD production process works. It requires a lot of man-hours dedicated to maintaining and checking the published annotative details. Clearly, one of Civil 3D’s critical design development goals is to spare organizations and Civil 3D users of this expensive man-hour burden and cost. The better idea here is to put the man-hours into the iterative engineering and survey 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. Heck. You may still refer to the software as AutoCAD Civil 3D. Our AutoCAD customization skills still apply. However, we must all too often apply them differently and much more systematically. Here’s why…
The Most Critical Standard - How You Name It
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 and behind 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”? In a minute, we’ll get to the structure of a customization namespace for Civil 3D references.
First, an important illustration.
Visualize 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 (DREF) from any project. Use the RENAME command on any of the raw 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 other properties of the Layers either – nothing visually changes.
This exercise is not too exciting until you consider carefully 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 for Civil 3D, we call them Spreadsheet Tools.
To be clear. Civil 3D customization must be managed systematically by external means or we must work way to hard.
There are a couple of key collections in the Civil 3D 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 named 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 we force Civil 3D to do this in our Civil 3D Styles.
From a healthy and practical 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 Bad News…
The current method when applied to make fixes is painfully repetitive and tedious.
The Practical, Mutual, and Agreed Self-interest
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 from better Civil 3D parts collections and resources. The NCS rules are remarkably flexible, robust, and adaptive simply because of how they came about. These Rules reflect the collected real world project deliverable experience of hundreds of firms and organizations.
The Standard Keys to Names
The NCS Layer Standard 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 cannot 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 Layer properties in Styles and/or Sets of Styles 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 Standard Keys page.
The customization key point is that the meanings (and even forms) 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 user 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 we get the deliver to the user.
Typically, the name is in a restricted pick box list.
We 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: Proposed Contours 1-5.
For the common and most understood Civil 3D 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.
A Choice of Style is more productive. Style Choice is not contrary to publishing standards unless you confuse and mix the two complementary 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 Civil 3D 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 product 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 and file store the data referenced, Civil 3D Features. That’s another story.
See The Elements of Style in Civil 3D post and links for more about Style Maintenance Management in Civil 3D.
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 into a customized publishing template. This two pronged working and publish 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.
We must endlessly customize Civil 3D.
We should reap the benefits.
The simple fact is that we’d all rather do what we already know how to do on autopilot.
The emergencies of the moment always tend to get in the way of the more serious and harder work we need to do to avoid them.
Register on the website and gain access to organized documentation and help for all the topics discussed in this post.
The Liberty to Make Civil 3D Work
Get the Framework for Civil 3D