Civil 3D Object Model Nuances

It is probably fair to say that I’m often more face down in Civil 3D Object Model nuances than a lot of daily Civil 3D users. That makes sense. My personal work depends on that. I 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 in the Framework for Civil 3D products. The Framework of Civil 3D products exist for multiple releases of Civil 3D and in multiple flavors based on customer demand.

Where’s the Civil 3D Nuance?

Most of the people I talk to everyday are advanced Civil 3D users, CAD Manager folks, and organization Project Managers and Principals trying to get work out the door and keep the wheels on the bus. Frankly, a lot of them are literally rebuilding the Civil 3D Magic Bus while it rolls down the road like that recent Mercedes commercial. That is truly an act of daring do. Something we all must do. The content of this blog and the Framework for Civil 3D itself, is focused on those needs and questions.

Honestly, the odds are your Civil 3D question has been answered here somewhere. Eheh. Probably in a form that is more than you 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. I hope it helps.

The Object Model Nuance and Civil 3D Dependencies

In the recent Manage Civil 3D Dependencies post, I attempted to address generally some vital method and process questions about dependencies and the numerous references in Civil 3D. We must deal with the Civil 3D practical reality that…

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

We want to preserve Civil 3D Feature data behind dependencies. The time comes when we don’t. Civil 3D users need to know the answer to the Why, When, and How. Sorry. There is no simple answer. Much depends on the context, timing, and you.

The identification of change of drawing State Benchmarks and our Heuristics (Rules of Thumb) play a significant role. We can use these to better address this significant issue that rests upon the Civil 3D users performing the work.
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. I 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 of making a Civil 3D Data Reference (DREF) a project resource without our Styles is complicated.
Some of my people don’t see the need to do this.”

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

We’re not cleaning the project DREF resources for them. Yes. The process will help them in the long run, but that is sometimes hard to see. We are doing the work for everyone one else and the upkeep and maintenance of the project.
In the end, the stability and performance of the project matters to everyone.

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

When in doubt it is worth the small extra effort to keep the data behind stored in raw (Styleless) Civil 3D drawings. The odds are Autodesk will do their best to make sure your data behind isn’t smacked or sent to hell in a handbasket by an Update to the 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. I think of XML as a generic term for a number of text-based file types - JSON, IMX, SHP, etc. This is a growing list.

Pay Attention to Interoperability

Autodesk interoperability initiatives are growing the number and details of supported file formats as we speak.
It pays to pay attention to all that software interoperability development particularly when there is a Civil 3D Update. I recognize that it seems a bit counter-intuitive to care about software you may never use.

Yesterday’s XML may have a new import/export file type that does what you need better and with less hassle even if you never need to use that other software that might require that improved file format.

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

These days interop forces external to the internal development of the Civil 3D Object Model probably drive 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 that data behind, the classic XML is for the most part static. It helps to recall that the XML file will remember When and Where the data came from. We all love audit when we need it. That day arrives sooner or later.

File-based dependent references are a bit more complicated to maintain if you must move the parent and children around. Most Civil 3D Feature file-based references do not support relative paths. That probably annoys you too.

Replacement and Substitution Strategies and Tactics

The external source file is also easier to update by overwrite or 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

Surface models must conform to published and recognized standards that Autodesk cannot and does not control. A DTM is a DTM. The XML of a Civil 3D Surface may be only the resolved DTM model of a Surface. It may contain none (or few) of the detailed properties that went into resolving the surface model in Civil 3D. This nuance matters. We tend get and want the results and retain none of the process data it took to get there.

An export/import of an XML of a Surface can remove the dependencies from a surface model. The classic issue might be you don’t want to include all the previous edits or direct connections to other source data objects (Points or Point Groups) in the published surface. The working surface to published surface issue triggers a change of state benchmark. Your agreed heuristics says what workflow you need to perform.

Parcels

The Civil 3D Object Model for Parcels and the support 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 DREF in Civil 3D. Therefore, XREF and/or IREF references and structures remain the Parcel backbone in most Civil 3D projects.

The odds are the Autodesk/ESRI interop initiative will change Civil 3D Parcels and perhaps dependency and reference behaviors in the future. There is a richer data behind available for Parcels.

Property Sets

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

The introduction (or 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 CAD 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 you. Currently, Property Sets are organization/user preference based. You are responsible to create, manage, and maintain the Civil 3D Property Set data definitions.

Because Property Sets are Styles you 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, your 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 project context. We should probably ask, “Is it working or published data?”

Property Set Wishes

Autodesk supplied resource support for formal Property Set definitions for most Civil 3D Features and their data behind is high on my Civil 3D wish list. When Autodesk changes the Civil 3D Object Model, they should produce a published Property Set definition that supports the Feature’s properties they choose to support.

I trust it is obvious that adding formal Civil 3D Property Set definitions capabilities to import/export file formats would increase overall interoperability functionality in the long run significantly.

Alignments

The Civil 3D Alignment super Feature is a lot more nuanced than a basic structure to contain horizontal control. We all get that. I purposefully employ the term Design Control Manager to talk about Alignments in Civil 3D. Almost all the best, manageable, and productive design functionality in Civil 3D is built from the ground up around Alignments.

See the Civil 3D Alignments posts that begin here.
Register and visit the entire Civil 3D Book of Alignments in the Members section. I can only briefly touch significant issues here.

There is no such thing as a simple Alignment in Civil 3D. Best to not forget it. Well more than half of the Civil 3D Toolspace tree 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 in 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 understand the bias and the need.

Grading design by surface breakline still works in Civil 3D thanks to Features Lines. It works better and better. Hoorah! I just happily embrace and prefer Corridor Feature Line outputs as results. The future of Groundforce may change my mind.

It is probably best to remind folks that Feature Lines are obviously all about Surface manipulation or edits as in the DTM 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 retarded Design Control Managers simply because they are bound to Surfaces. They are good for the quick one-off problem solutions and some details that are difficult and/or too time consuming to pull off within a more managed Corridor model.

Feature Lines are dangerous ground to try and build managed design control structures around in Civil 3D. By that I mean that we would, or should, all prefer easier to change adaptive design over detailed and repetitive work.
In other words, optionality matters. See The Multiplicity of Civil 3D Drawing Types post.
Feature Lines require that we manually perform too much work. Experience in Civil 3D predicts that if you do it manually you will probably have to throw it away or do it and do it and do it.

Call Me Lazy

I advocate these stranger things for Civil 3D – That affordable, doable, and adaptive options are the most vital product requirements. Those things create real value over the long haul for those that do 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.

The Civil 3D That Makes Sense
Get the Framework for Civil 3D

 

Civil 3D Dependency and References Posts