Jump Kit

The Framework for Civil 3D
Get More

Templates Only

See The Framework Work
Get More

Become a Member

Master Civil 3D
Get More

Autodesk Civil Videos

Free Civil 3D Training
Get More

Framework Videos

Free Civil 3D Videos
Get More

For reasons that deserve explanation, Autodesk Civil 3D includes some apparent contradictions. There are formal sets of dualities built into Civil 3D. Whether we perceive and/or employ these model-based software pairings for our benefit is another matter. Sadly, every Civil 3D user struggles with these dualities to one degree or another.

Frankly, it’s even a bit difficult to talk about the apparent contradictions in Civil 3D without sounding confused. We can easily appear to parrot a technology sales person, a hack politician, or an existentialist philosopher.

Civil 3D Features are Stranger Things

Exactly what do we mean by these dualities?

Some things in Civil 3D are simultaneously inseparable but are indeed separate things.

  • A Civil 3D Feature and its Styles are inseparable but are separate things.
  • A Civil 3D Feature and its Settings are inseparable but are separate things.
  • A Civil 3D Feature 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 the famous AutoCAD OOPS command even if we may want the unforeseen consequences of this OOP to go away or maybe even never come back again.

OOP is Collective

These OOP principles mean that every 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.
A Feature Style in OOP (and therefore in Civil 3D) is a separate and related collection of properties that represents a Feature and it’s collected objects in more than one fashion.

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

The Power and The Pain of Limitless Possibility

Autodesk Civil 3D has an immense number of parts and pieces. These must work together in a cohesive manner. All the OOP stuff is based on the key principle of the Power of Names.

Our arbitrary names exist to help us manage - By Name - the immeasurable number of potential property choices systematically. There’s a mouthful.

Unspoken Truth

The system to help us manage these unlimited collections of properties is organized by Civil 3D Settings.
The Civil 3D help file says the Settings have a top down hierarchy of Drawing Settings, Feature Settings, and Command Settings.
However, we soon recognize it’s 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 have built-in Parent and Child behaviors. Child Label Styles can and do inherit properties from their Parent.

The entire Settings system in Civil 3D operates in a hierarchical fashion. The Feature Settings Defaults and the more complex LSD (Label Style Defaults) structure allows managers 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…
Our Label Styles better be constructed to honor that 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 our bad driving or our failure to maintain the car’s brakes or tires.

Failure beyond our control does happen in Civil 3D, but that occurs far 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.
Note: There are both Civil 3D Template builder and everyday Civil 3D user accountabilities here.

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

Get the Drawing Settings Right

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

Get the Feature Settings Right

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

Label Style Construction and Maintenance Issues

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

  • In a Label Style always Add and Name the components in the Parent Style
  • Never change the component Name in a Child Style
  • Be careful of connecting the component parts differently in Label Style Children
    A stable pattern and structure of Label component geometric connections is critical to Label Style stability in release and updates.
  • Expressions employed in Label Styles cannot be renamed only rebuilt
  • Collect Expressions employed in Label Styles in one management and maintenance Label Style that references all the Expressions
    Add references to the Expressions inside the Label Style Composer to include them.
  • Always Import an Expression collector Style first.
    This is why we employ and name these Always Import Styles included our products.
  • Adjust the Default Settings for our common usage in our working template(s)
    Our publication templates may, and probably will, have different Defaults
  • Document our Command Settings changes
    This practically means we have one or more resource drawings that store the Command Settings.
    Command Settings
    resource drawings are usually different from the Settings sources.
    As a Civil 3D User, we know where the Command Settings are stored in our working environment.

What about the Command Settings?

The Feature Command Settings will employ the Feature Settings plus the Civil 3D command’s specifics unless we change the Command Settings in a drawing or a template.

Civil 3D is far from perfect about obeying this general rule.
Sadly, that varies from release to release and update to update as well.
More recent Civil 3D releases behave more consistently.
However, new Civil 3D commands in all releases or updates are notoriously inconsistent.

Creation Command Issues

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

This simply means we must pay attention to the obvious fact 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 raw AutoCAD users we’re simply not used to the idea that Styles would be related to and reference one another. The ACAD classic Styles: Layer, Block, Textstyle, Linetype, and Plotstyle do not have a formal relationship with one another.
The AutoCAD Style 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 these more complex references. We must be more formal regarding the maintenance of those properties.

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

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

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

LSD Bends Our Minds

When we check out the Label Styles in the Toolspace>>Settings tab we also discover that Civil 3D Label Styles have Label Styles Defaults (LSD).

At its many levels LSD allows us to control and manage the many properties of our Label Styles by Drawing, by Feature, and by Type.
For example for some Features like Alignments and Profiles there are many Types of Label Styles.
Therefore, each Type may have its own forms of Label Style Defaults.

The Framework products for Autodesk Civil 3D rely on and obey the above Hierarchy Rules.

Therefore, quicker Style and Label Style changes are easier perform.

Significantly, changes are then far easier to maintain in our resource drawings, our various forms of templates, and our project drawings.

Make Civil 3D Work Better
Get the Framework for Civil 3D

 

The User Rules for Civil 3D

Updates, additions, and fixes to the posts in this series are on-going.