Civil 3D Surface Care

The title for this post sounds almost like a car finish product. Go on down to the box store and pick up some Surface Care today. Civil 3D Surface Care is in the aisle next to that beer sold by dem Artesians. You remember the Artesians? Don’t you? Ok. Maybe not. You should.

The Artesian tv spots were the best of the 80’s beer commercials. You have to wonder what a mint condition  and unused “I Seen ‘Um” bumper stick is worth today?

Are There or Aren’t There Artesians Theme Song

History shows us these great tongue in cheek commercials were, unfortunately, not backed by a well-crafted beer. Not the least problem with the ole Oly was a tendency to fizz and then go flat too fast.

Civil 3D Surface Care and Feeding

Your Civil 3D project’s existing surface DREF may advertise a great surface. Does it deliver?

Most people start out in Civil 3D mucking all the stuff together same the way we did in back in LDT days. One survey drawing with all the stuff on discrete layers. In Civil 3D terms: A surface model, points collection, maybe even a parcel collection, etc. all in one container drawing.
This bunch method where DREFs and/or XREFs are pulled from the same source works fine until it doesn’t. People may not even question the methodology.

The Framework sample projects never employed this methodology. There are some good reasons Why to employ separate

LandXML-based DREF Surfaces

LandXML is the defacto (non-proprietary) generic text format for the surface data, so what the heck.

The chief reason…

Survey folks don’t want the design folks to stomp on their published surfaces.

A DREF container drawing with a reference to an external LandXML-based surface model in a file works pretty well.

• Project and drawing performance is pretty good.
  Check the file for LandXML (XML) file changes and use the Snapshot if nothing has changed.
• I think by default Civil 3D loads the Snapshot and then checks for difference these days.
• The Snapshot is the internal surface model build and what actually gets shared via the DREF.

Understanding what a Civil 3D Snapshot is and does seems vital.

Snapshot Reality

From the Civil 3D help files- A snapshot is a surface operation that captures the current state of surface:

• The current surface points and triangles resultant from previous surface operations are contained in a surface snapshot operation.
• When a surface is built, previous surface operations are ignored and the surface build begins at the snapshot operation.
• Surface operations that are included in the snapshot are marked with a camera icon in the Prospector tree.
• Snapshots can also be created automatically.
  A LandXML setting enables you to specify that a surface snapshot be created in the surface definition subsequent to the importing of a surface when using Import LandXML command.

Technically, the DREF LandXML reference device protects the survey folk only somewhat.

Nothing can defend them from all cases of surface abuse and misuse.
You can edit and add content to an XML based surface.
But a cleanout of an edited Surface stack; a reload of the file; and recreation of the Snapshot from the XML file data resolves the issue of mistaken edits.

Surface Updates

Surface Updates are as easy as replacing the source LandXML file and reopening the DREF container and rebuilding the Snapshot.

• This form of update propagates through projects effectively.
• An update doesn’t necessarily mean you lose the annotation you previously tied to the DREF surface.
• Location-based labels always demand a QAQC check.
• Most firms seem to want that to be a DREF consumer’s accountability.

Remember that if you have a very detailed set of lines needed to create contour and/or two-point slope label annotation, it may pay to WBLOCK them out to separate drawings just in case.

What’s in the LandXML Data?

We want clean straight paths for the data in Civil 3D.

Surface models in Civil 3D can ONLY include x,y,z surface points and breakline couplets of points by definition. Everything else in the Civil 3D Toolspace is a routine illusion to get to the same places.

The US DOD and the USGS on the surface made this rule and paid/pays handsomely to have the definition in the public domain. Given the two arrays and the same data processing algorithm surface model code should reproduce consistent and repeatable resultant surface models.

The input data is two text files. The output data in Civil 3D a TIN surface model.

Therefore, the clean straight path to a surface model is an external point file source and a managed/manageable set of breakline edits.

Technically, point data included in a Civil 3D Figure definitions is duplicate point data. It exists in both arrays. Those duplicated points should be removed from the external point file source.

First Principal Points

Some first principals are a factor in Civil 3D…

• Civil 3D collects everything whether we expect, or want it to, or not.
• All Civil 3D Feature data behind interactions must be managed by users.
• It pays to separate the data behind more so the annotative flexibility built into Civil 3D can be better employed.

I call this the Separation of Powers.

I think I already said in earlier posts that the survey output is best done in 5 or more separate drawings. See the Civil 3D Survey Project Prototypes post. That seems like overkill until you do it and reap the benefits of getting to better results faster.

At least you should separate linework geometry from annotative labels at the minimum.

Surface Points and Points

The Points and Surface relationship (a critical path data behind interaction) in Civil 3D is often the most problematic in real projects for users. The surface definition changed. What a point is changed. Folks stumble over these stones.

A point in Civil 3D is really nothing like an AutoCAD block. There isn’t even such a thing as A point in Civil 3D. Points are always collected.

The Point collection itself determines what a point looks like and how it is labeled by membership.
Read that sentence again.
It is NOT Civil 3D (the software) doing the work.

• Points in a drawing always resolve to a set of two display resolution STATEs.
  A point style and a point label style.
• Points always have resolved membership.
• Points are performance piggy when they are displayed.
  In practice, Point Selection can be performance painful.

It is the Point Feature collection itself that produces the resolved results. This core OOP concept of programmed behaviors underlies all Civil 3D Features.

Surfaces and Point collections display themselves. We hear the words but don’t always believe what they mean. We stumble over the problem. If it looks like a duck - it will behave like a duck. Recall that Civil 3D is doing the looking.

The Civil 3D Toolspace>>Prospector tab tells you where the data behind is for all COGO Points – In the All Points point group. This you should take seriously. Is there any other data is any other point group? What data is that?

You should also ask, Where is this Survey Point? In the drawing? or in the SurveyDb? Better yet – Where do you really edit a Survey Point? Survey in Civil 3D is more complicated until you understand Why it is more complicated. Then not so much.

All of that Points to a Surface

If you put a Point Group into a Surface Model, the drawing’s the Points collection must resolve the data in that Point Group before the Surface Model can be resolved.
Civil 3D does this quickly.

Any resolution time is worth it while the membership of the points in the surface model is still in flux.
When that membership is resolved, the dynamic Point Groups in a surface just make the surface model potentially a lot more open to destruction and abuse. They become dangerous.

Points in a published surface model container drawing are unnecessary. We don’t need them. Points are potentially nothing but a problem and/or just confusing. An external x,y,z surface point file reference is safer, cleaner, and easy to both produce initially and update when necessary.

All of the above principals work well for classically gathered survey data and surfaces.

Somewhat like beer recipes the water can make a difference or not. That means we will continue to live with the Are There or Aren’t There Artesians question.

More Forms of Surface

If your surface models are derived from Lidar-based or photo-based resources the storage medium of your existing surface model is going to change.

We want clean straight paths for the data in Civil 3D.

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

 

The Civil 3D Issues to Chew On Post Series