The Civil 3D Hierarchy Rules

Tags implementation, training, bucket, Name Template, dynamic model, names, Style Management

There are a formal sets of dualities built into AutoCAD Civil 3D. Whether we perceive or employ these model-based software pairings for our benefit is another matter altogether. Every Civil 3D user struggles with these dualities to one degree or another. Frankly, it’s even a bit difficult to talk about them in Civil 3D without being a bit confusing. You can end up sounding like a technology sales person, a politician, or an existentialist.

Civil 3D Features are Stranger Things

Some of the inseparable but are separate things - Formally, a Civil 3D:

  • Feature and its Styles are inseparable but are separate things.
  • Features and their Settings are inseparable but are separate things.
  • Features and the commands that create, edit, and manage them are inseparable but are separate things.

We get this distinctive two-faced madness because of the OOP (Object Oriented Programming) core principles that unpin the model-based roots of Civil 3D. The OOP here is not an AutoCAD command even if we may want the unforeseen consequences of OOP to go away or maybe even never come back again.

OOP is Collective

These OOP principles mean every single Feature in Civil 3D is a collection of objects. In OOP speak a Feature is a programmed group of related objects that work together. Each object is itself a collection of properties. Style in OOP and therefor in Civil 3D is a separate and related collection of properties that can represent a Feature and it’s collected objects in more than one way.

The concepts of the Data Behind, Style, Parent Child relationship, and system Hierarchy are all baked in. We are allowed to visualize and manage the parts of this structure in the Civil 3D Toolspace in the Prospector and Settings tabs.

AutoCAD Civil 3D has an immense number of parts and pieces that must work together in a cohesive manner. All this OOP stuff based on the Power of Names exists to help us manage By Name the immeasurable number of potential property choices systematically.

Unspoken Truth

The system to manage these unlimited collections of properties is organized by Civil 3D Settings.
The help file says the Settings have a top down hierarchy of Drawing Settings, Feature Settings, and Command Settings. However, we soon recognize it’s really more complicated than that.

Each specific Civil 3D Feature has their own Settings plus Label Style Defaults (LSD), and Feature Label Type Settings too. The Label Styles also have built in Parent and Child behaviors. Child Label Styles may inherit properties from their Parent.

The entire Settings system in AutoCAD Civil 3D operates in a hierarchical fashion. The Feature Settings Defaults and the more complex LSD structure allows you and everyday users to apply consistent and specific property changes to entire collections of Label Styles.

Simply put – almost any shared or common property changes may be cascaded downhill from a particular branch in the Civil 3D Toolspace>>Settings tree.

Left unspoken…Your Label Styles better be constructed to honor the hierarchy.

Many people assume that a Civil 3D template is responsible to do and maintain all of this. That’s like blaming the car for your bad driving or your failure to maintain the brakes or tires. Failure beyond our control does happen, but less often than we claim.

The Hierarchy Rules for Civil 3D

Get the Template Settings Right

These basic rules apply to all and each level of Settings. There are both template builder and everyday Civil 3D user accountabilities here.

  • Adjust the Default settings for your common usage in you working template(s)
    Your publication templates may, and probably will, have different Defaults
  • Document your Drawing Settings changes
    This practically means you have one or more drawings that store the Settings
    As a Civil 3D User you know where these are stored.

Get the Drawing Settings Right

  • Check Drawing Settings in new drawings
    This is a fundamental Civil 3D User responsibility
  • Review Drawing’s Label Style Defaults
    This is makes sense if you want to be a productive Civil 3D User

Get the Feature Settings Right

  • Check the current Feature Settings before you bring in data or start a task
    This is a fundamental Civil 3D User responsibility
  • Review Feature Type Label Style Defaults
    This is makes sense if you want to be a productive Civil 3D User
  • Employ Label Style Defaults to make fast consistent changes by the appropriate Feature Label Style Type (level in the Toolspace tree).

Label Style Construction and Maintenance Issues

We want this to be in the templates, but practically your templates and Style collections don’t tend to improve if your Civil 3D users are ignorant of these rules and break them.

  • Always Add and Name the components in Label Style in Parent Styles
  • Never change the component Name in a Child Style
  • Be careful of connecting the component parts differently in Children
    A stable pattern of Label component geometric connections is critical to Label Style stability in release and service pack updates.
  • Expressions employed in Label Styles cannot be renamed only rebuilt
  • Collect Expressions used in Label Styles in one Label Style that references all the Expressions
    Add references to the Expressions inside the Label Style Composer to include them.
  • Always Import the Expression collector Style first.

What about the Command Settings?

  • Adjust the Default settings for your common usage in you working template(s)
    Your publication templates may, and probably will, have different Defaults
  • Document your Command Settings changes
    This practically means you have one or more drawings that store the Settings
    As a Civil 3D User you know where these are stored.

The Feature Command Settings will employ the Feature Settings plus the Civil 3D command’s specifics unless you change the Command Settings in a drawing or a template.
Civil 3D is far from perfect about obeying this general rule and that varies from release to release as well. Recent Civil 3D releases are more consistent, but many new command functions in all releases are notoriously inconsistent.

Honestly, the Command Settings are a bit more problematic especially when we talk about Creating a Feature. At the moment of creation we often must make design time decisions about the Feature we may not be able to change later. Because of other Settings already in place, many of the potential choices may be eliminated by the time we get to the specific Command’s Settings we’ve set.

This simply means that humans are first and foremost creatures of habit. The Command Settings work well to optimize USER design time choices by reducing the choices, but doing too much of that form of optimization also reduces the flexibility and the need to make conscious choices at the same time. That isn’t always the most efficient and productive thing to do. Use tweaked Command Settings in moderation.

The System Collects or Collects Me Not

As AutoCAD users we’re simply not used to the idea that Styles would be related to and reference one another. All of ACAD classic Styles: Layer, Block, Textstyle, Linetype, and Plotstyle do not have a formal relationship with one another. The relationships exist only in our own minds and how we use the software.

Since Civil 3D Style is another step up in Style abstraction (things point to other things) the software must be more formal about all the references and the maintenance of their properties.

  • The collected data behind for a Civil 3D Feature is separated from the Feature’s Style and Label Styles representations which themselves are separate collections of properties.
  • The many properties can only be practically managed because there is a formal hierarchical relationship between the collected members.
  • In many cases this also means there is a formal relationship between different collectors within the Civil 3D object model.
    For example - There is no such thing as a Profile without a parent Alignment.
    Alignments collect Profiles whether we like it or not.

The vast majority of Styles in AutoCAD Civil 3D are annotative. These express the collected data behind in alpha-numeric and/or text formats. Mostly these are Label Styles although Table Styles can also help us publish data pretty significantly.

We should also consider that all of the View Features in Civil 3D are annotative as well. The Views just couple the alpha-numeric and/or text with specific forms of linework, the grid, hatching, etc with the purpose of publishing the Feature’s data behind – a Profile View, a Section View, a Superelevation View, etc.

LSD can Bend your Mind

When you check out the Label Styles in the Toolspace>>Settings tab you also discover the Label Styles have Label Styles Defaults (LSD).

LSD at it many levels allows you to control and manage the many properties of your Label Styles by Drawing, by Feature, and by the Type. For some Features like Alignments and Profiles there are many Types of Label Styles. Each Type may have it’s own Label Style Defaults.

All our Framework products for AutoCAD Civil 3D rely on and obey the Hierarchy Rules. Therefore quick changes are easier to do and far easier to maintain in both templates and project drawings.

Get the Power Beyond the Code
Get the Framework for Civil 3D

Civil 3D User Fundamentals Posts