A First Civil 3D Reference Template Stack

Tags Reference Template, Style Management, template, implementation, Civil 3D 2017

We’ve set out on an Unexpected Journey. In AutoCAD Civil 3D 2017 we have a new Reference Template Tool offered up with the idea of a State Template>>Company Template>>Project Template hierarchy and vernacular. It works as a sales pitch. Sadly, this vague Civil 3D help file expression of the idea pretty much ignores some of the realities of the Civil 3D Style and Settings mechanics necessary for actual production and publication use.

That does not mean that Reference Templates are a bad thing. Things are just a bit more nuanced than we first suppose. This is Civil 3D template customization after all. I doubt you are surprised.

A Reference Template Stack in Civil 3D

“What goes in there?”

  • The Reference Template stack needs a proper context to function well.
    We explained the need for a Root Template and Setting Template resources previously.
  • The Reference Template stack has priority.
    We have to seriously consider and manage that order.
  • The core Civil 3D display Feature representation Styles are one set of choices
    the annotative Label Styles and Sets are something else again. More about that later.

So many choices. We do have to make choices. This gets a little dicey when we move from all-inclusive templates to a new task-based and/or system-based templates and maybe that new Style Management paradigm. Seriously…

You Don’t Have To Do That

If you don’t want or need to go that far, read the post A Civil 3D Root Reference Template and last post Civil 3D Settings Reference Templates and you can skip the rest of these posts. Come back and visit the more arcane magical stuff when that basic template setup all works in the real world and in your real world projects.

“Dave? Can our Civil 3D Templates and Styles Do That?”

Like the man said, “Make it so.”

You’ll have a Root Template, a Settings Template, and a single template resource in the Reference Template Stack. This works. We get real and immediate benefits:

  • Less likelihood users step on the Styles
    All the Styles come from one known good
    User alterations might seem to be a bit more visible
  • More Style Consistency
    Style is not individual to a drawing
    Provided users obey a don’t mess with it rule
  • A bit more Flexibility and Adaptability
    In on-going projects Styles can be updated easily from one known good
    Style can be added more easily
    Styles can be exchanged if you employ a common and rigorous naming convention
    In practice - Style removal and demotion is another matter entirely
  • A bit more Robust system
    Every Style is a reference not defined in the current drawing
    Except for the Civil 3D Settings which matters perhaps more than we might like
    You know where to go to fix referenced Styles if they break

All that is sort of magical. True. Some new Civil 3D user competency and practice is required. This is doable. We must do the do.

  • For in progress project work users do have the choice not to update
    You can thoughtfully combine the Reference Template Tool and specific Reference Template Stack naming conventions to manage updates.
    You can do replacements too.
  • For publication you can start new Root Templates, Setting Templates, and another Reference Template Stack and load Civil 3D feature references from the project.
    You’d better very carefully store the references.
    But nothing really new here regarding Intelligent Publish On Demand (iPOD).
    That got easier.

Reference Templates are Better

We can all more happily live with those results. The magic ring helped. You’ve become a master burglar; opened the hidden door; and found the pile of gold in the Lonely Mountain as it were. The dwarves will be happy. Hoorah!

Get the Magic of The Framework for Civil 3D

Dude! You woke the dragon.

Reference Templates in Civil 3D