Civil 3D Object Model Nuances

Most of the people we talk to everyday are advanced Civil 3D users, CAD Managers, and organization Project Managers and Principals who try to get work out the door and keep the wheels on the bus. Many of these folks are literally rebuilding the Civil 3D Magic Bus while it rolls down the road.

That is truly an act of daring do. That is also something we all must do.

Around here we are often more face down in the Civil 3D Object Model nuances than a lot of daily Civil 3D users. That makes sense. Our work depends on that. We build, support and help people implement Civil 3D production environments with the best in-depth collections of Civil 3D Styles, Civil 3D Templates, and other vital Civil 3D resources available on the planet.

Those Civil 3D resource jewels are found  in the Framework for Civil 3D products.
Jump Kit and Templates Only are available for multiple releases of Civil 3D.

Where’s the Civil 3D Nuance?

The content of this blog and the Framework for Civil 3D itself is focused on these needs and questions.

The odds are your Civil 3D question has been answered here somewhere. Eheh. Probably in a form that is more than we ever wanted to know about the topic. It is also fair to say that this site in one of the deepest and continuously developed Civil 3D content sites on the web.

The Members and Videos sections are better organized to help you find answers to mission critical Civil 3D questions.
Register here. It is free. We hope it helps.

The Civil 3D Object Model Nuance and Dependencies

In the Manage Civil 3D Dependencies post, we attempt to address some vital method and process questions about dependencies and the numerous type of references we employ in our Civil 3D projects and drawings. We must deal with the practical reality that…

Dependencies in Civil 3D are good news until they aren’t.

We want to preserve Civil 3D Feature data behind dependencies. Then the time comes when we don’t. Civil 3D users need to know the answers to the Why, When, and How. Sorry. We work in the real world. There is no simple answer. Too much depends on the project context, timing, and our priorities.

How We Make Decisions

The identification of change of drawing state Benchmarks and our Heuristics (Rules of Thumb) play a significant role in how we can help our Civil 3D users to perform the work. We use consistent benchmarks and regular workflows to better address the significant dependences and references issues.

In a Civil 3D project, a Managed Dynamic Model is a mission critical Civil 3D user accountability.

There is a third leg to the practical, stable structure we need to include. We allude to this in the post mentioned above.
Civil 3D Object Model issues deserve more nuanced considerations. They pertain to the Why, When, and How Civil 3D user issues and skills we must all address.

Common Object Model Project Management Questions

“The mechanics to make a Civil 3D Data Reference (DREF) that doesn’t contain our custom Styles is complicated.
Some people don’t see the need to do this.”

See the important Styleless Data References in Civil 3D post and the Styleless DREF Mechanics in Civil 3D post follow up.

We do not clean our Civil 3D project DREF resources for them. Yes. The workflow process will help them in the long run, but that is sometimes hard to see.
We do this maintenance work for the upkeep of the Civil 3D project and everyone one else.
The stability and performance of the Civil 3D project matters most.

A Civil 3D drawing is more stable and performs better when it has none of our custom tweaks included. Truth be told, the Styleless DREF mechanics are not that complicated. The mechanics may be just new and a bit different.

When in doubt it is worth this small extra effort to keep the data behind stored in raw (Styleless) Civil 3D drawings.

We bet that the odds are Autodesk will do their best to make sure our data behind stored in the stock objects isn’t smacked or sent to hell in a handbasket by an update to their Civil 3D Object Model code.

“When can we employ an XML file as a dependency in a DREF?”

This is a loaded question that speaks volumes to the dependency and reference nuances of the Civil 3D Object Model and those effects on our Civil 3D projects.

There are more than XML file structures that Civil 3D can export and import. We can think of the XML file name as a generic term for a number of text-based file types - JSON, IMX, SHP, etc. There is an ever growing list of these potential referenced file types.

Pay Attention to Interoperability

Autodesk interoperability initiatives grow the number and details of supported file formats as we speak.
It pays to pay attention to all that software interoperability development particularly whenever there is a Civil 3D Update.
Yes. It does seem to be a bit counter-intuitive to care about software we may never use.

Even if we never need to use that other software, the new import/export file type and format support may include new capabilities that better deliver what we need with less hassle.

Back in the day, the Civil 3D development team(s) tweaked the Civil 3D Object Model. Sometime later the group produced an XML or export/import file version. By definition these routines of any type dumb down the detail from the actual Civil 3D data behind. The Autodesk code controls what is available in the export/import file type.
New code may allow us to better manage the results. Hoorah!
These nuances change from Update to Update. It pays to pay attention.

In recent times, the external interoperability forces tend to drive the internal development of the Civil 3D Object Model and the nuanced Object Model details more for very practical reasons.

What Was…Is and Isn’t

Back to the when XML question…

For well-established and older Civil 3D Features and their data behind, the classic XML is for the most part static. Please remember that an XML file remembers When and Where the data came from. We all love that simple form of audit when we need it. That day arrives sooner or later.

Civil 3D file-based dependent references are a bit more complicated to maintain if we must move the parent and children drawings around. Most Civil 3D Feature file-based references do not support relative paths. The lack of relative file path support for these data references supplied by external files probably annoys you too.

Replacement and Substitution Strategies and Tactics

An external file data source is easier to update by overwrite, by file replacement, and/or substitution. Therefore, level of detail replacement by direct file substitution is relatively easy to maintain. We should establish known benchmarks and heuristics to trigger consistent and appropriate level of detail change workflows.

Surfaces

We must keep in mind that Surface models must conform to published and recognized data standards that Autodesk cannot and does not control. A DTM is a DTM.

The exported XML of a Civil 3D Surface may be only the resolved DTM model of a Surface. That data may contain none (or few) of the detailed properties that went into the actual resolution of the Surface model inside Civil 3D. This nuance matters.

We tend get and want the final results and retain none of the process data it takes to get there.

An export/import of an XML of a Surface can remove the dependencies from a Surface model.

We don’t want to include all the previous manual edits to the Surface or direct connections to other source data objects (Points or Point Groups) in a published surface.
This working surface to published surface event triggers a change of state benchmark.
Our agreed to heuristics says what workflow users then need to perform.

Parcels

The Civil 3D Object Model for Parcels and the supported XML output has been pretty much unchanged for too many Civil 3D releases. Regular benchmark and heuristic driven XML export/import remains one of the better backup and archive workflows for productive Parcel workflows in Civil 3D.

For reasons still unsaid, Parcels cannot be a Data Reference (DREF) in Civil 3D. Therefore, XREF and/or IREF references and structures remain the Parcel backbone in most Civil 3D projects.

There is potentially a richer data behind available for Parcels. The on-going Autodesk/ESRI interoperability initiative may eventually change Civil 3D Parcels and perhaps dependency and reference behaviors in the future.

Property Sets

Property Sets and their dependency issues in Civil 3D are not usually the first nuance we consider. If we use Property Set data, we do. If we don’t, we won’t.

The enablement of Property Set Styles in Civil 3D is far from insignificant. Property Sets make available a richer data behind for all Civil 3D Features and even AutoCAD primitives.

A Property Set is a managed data collection that may be applied to any object in the Civil 3D model for any reason that makes sense to us. Currently, Property Sets are organization/user preference based. We are responsible to create, manage, and maintain the Civil 3D Property Set data definitions.

Because Property Sets are Styles we can reuse and improve them. That it not the same thing as moving the data attached by the Property Set around successfully. We could replace moving with removing in that sentence.

Presently, our best project maintenance bet is to keep all Civil 3D Features with attached Property Set data always inside Civil 3D drawings. Once again, Styleless DREF storage containers are the safest bet if the Features are shared into the Civil 3D project context.
We should probably ask, “Is the Property Set data working or published data?”

Alignments

The Civil 3D Alignment super Feature is a lot more nuanced than a basic structure that only contains classic horizontal control. Most Civil 3D users get that. We purposefully employ the term - Design Control Manager to talk about Alignment Features in Civil 3D. Almost all the best, manageable, and productive design functionality in Civil 3D is Alignment centric.

See the Civil 3D Alignments post series that begins here.
Register and visit the entire Civil 3D Book of Alignments in the site’s Members section.
We'll only briefly touch on significant issues here.

There is no such thing as a simple Alignment in Civil 3D. Best to never forget it.
Well more than half of the Civil 3D Toolspace tree interface relates directly to the Civil 3D Design Control Manager. There is literally a sea of mission critical potential Object Model nuanced, potential dependencies in even a single line segment Alignment.

The Civil 3D project critical path is centered around Civil 3D users keeping all those many Alignment Object Model dependencies intact and appropriately managed within the Civil 3D project context.

It must be said that our old school civil engineering and survey CAD benchmarks and heuristics die a cruel death when applied to attempt to cope with Civil 3D Alignment Object Model nuances in detail. We knew how to measure, manage, and control the horsepower of carts and wagons. Planes, trains, and automobiles behave nothing like carts and wagons.

In general, many Civil 3D users assume too much and expect too little. If you want more production out of Civil 3D, the Alignment is one of the most important places to address with skills to deliver more.

Styleless DREFs remain the best way to manage and maintain Design Control Manager functionality. Alignment creation, management, and maintenance workflows have many more subtle change of state benchmarks. All the many Alignment children matter. Civil 3D users must learn to identify and respond correctly to them.

All of the more advanced and productive Civil 3D user skills require solid grasp of Civil 3D Alignment method and practice coupled with practical Alignment management, reference, and maintenance skills.

Feature Lines

“Why can’t we DREF Feature Lines?”

I might answer – “Where’s the forest? You are talking about trees.”

I freely admit to being a Design with Corridors advocate. I often give the Feature Lines Only crowd out there in Civil 3D Land a hard time. I do understand the bias and the need.

Grading design by surface breakline still works in Civil 3D thanks to Features Lines. Recently, it works better and better. Hoorah!

I just happily embrace Corridor Feature Line output as more manageable results.

The Feature Line based output results of Grading Optimization’s tools may come in a close second.

It is probably best to remind folks that Feature Lines are obviously all about Surface manipulation or edits as in the classic DTM construction mantra - Points are Data and Breaklines Edit.
When all is said and done, Feature Lines define TIN edges in a Surface model.

Feature Lines are somewhat retarded Design Control Managers simply because they are bound to Surfaces. They are good for the quick one-off problem solutions and those surface details that are difficult and/or too time-consuming to pull off within a more managed and complex Corridor model.

Feature Lines are dangerous ground to try and build managed design control structures around in Civil 3D. We would, or should, all prefer easier to change adaptive design over detailed and repetitive work.
In other words, design optionality matters.
Feature Lines often require that we perform too much manual work.

Experience in Civil 3D predicts that if we do it manually, we will probably have to throw it away and do it again and again ad nausea.

Call Me Lazy

I advocate these things for Civil 3D:
Affordable, doable, and adaptive options are the most vital product requirements.
Those things create real value over the long haul for those that perform the work.
Those that don’t and won’t find it hard to see them or even the benefits of them.

That good news and bad news comes with the territory in Civil 3D Land.

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

 

Data Relationships in Civil 3D

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