Civil 3D Figures happen to be a most excellent adventure in how the simple is sophisticated. This post resolves to save surveyors and civil engineers man-hours in ways you do not expect.
CAD people tend to trust in the picture. AutoCAD Civil 3D does not. We can create Civil 3D Features from CAD primitives (yes even non-ACAD ones). We can explode and export from Civil 3D Features and get ACAD primitive results. From a productivity standpoint, it does not serve us well to believe that Civil 3D Features are simply disguised AutoCAD CAD primitives.
The familiar is not always friendly.
These facts matter to surveyors and civil engineers alike.
Civil 3D Feature Resolution Basics
All Civil 3D Features resolve from the data behind. This means they interactively figure themselves out from the data we provide. All Features in model-based software also display themselves. Nether AutoCAD or Civil 3D do it. The Features do. We are responsible to manage that. Assigned Style defines the display representation and the annotated result.
Publication is only one of the goals of Style. The published Style is not necessarily the most productive game. Style is intentionally temporary in the iterative engineering environment of Civil 3D. The big advantage of Style tools is our choice how to see and annotate the data behind.
The challenge is to make choice manageable so we don’t waste all our time tweaking Styles to get what we need to get work done. That challenge is, in part, what the Framework for Civil 3D is all about. Our customers say we do that really well.
In the Recorded Line Work in Civil 3D and The Civil 3D Survey One and Many posts we previously explored the Civil 3D’s new Survey basics and essential linework create and edit tools. As promised, this somewhat deferred post is the focused follow-up on the arts of the recorded linework of Civil 3D Figures.
Chew on These Figure Resolutions
There’s a lot to cover. Civil 3D Figures are more data rich and more evolved linear Feature than LDT breaklines (only add connection segments into TIN surfaces). Here’s the brief but arguably WTMI list:
- Figures may be connected to Survey point data or not.
That not is easy to miss.
- You can build Figures and store them in Survey Dbs, in LandXML files, AutoCAD drawings, blocks, and even in Site Parcels.
Who knew you had so many choices?
- Figures always relate to a Site Parcel whether you like it, care, understand that, or not.
You want to publish Civil 3D figures from Survey Dbs into clean drawings.
- Figures have complex Style that also includes Marker Styles at nodes.
That can be annoying for publication, but helpful for visual identification to QA them.
- Figures have their own forms of Line and Curve labels.
There are both single segment and multiple segment Label tools.
Sadly, Figures, like Feature Lines, do not include support for Group Labels.
- Figures are not Feature Lines, or Parcel segments, but they share many common properties and common Ribbon panel Edit interfaces.
That can be a bit confusing, but the information supplied in common Ribbon Panel Tools can be enlightening.
- Many common site structures that are actually many related figures that can be collected in a faster standardized way.
We call this BESTWay figure collection (Bottom, Edge, Slope, Top, Wall).
- Civil 3D Figures may have complex related children.
That means 3D multi-line structures that you define and manage.
The Process Linework command can update them.
- See Special Codes in Civil 3D 2020 help
- See Special Codes in Civil 3D 2019 help
- See Special Codes in Civil 3D 2018 help
- See Special Codes in Civil 3D 2017 help
- See also the Line and Curve Segment Codes help.
You can use this capability in design with some thoughtful planning and use.
Sadly, we cannot separately Style the children of Figurative parents.
- Figures interact natively with Points, Parcels, Surfaces, and with Corridors subassemblies as control.
- Figures easily convert to Feature Lines and lose data connections to Survey points which makes civil design people happy.
- Exported Figures easily FLATTEN to create ACAD linework which makes AutoCAD folk happy.
Figure Generation Resolution
“The familiar is not always friendly.”
If you import point files as COGO points into working drawings by default you are actually almost always making more work for yourself. The old Import COGO points way is slower and more painful. Make a Survey Db your friend.
If you manually connect the point dots as a regular part of your work, you need to fix that. Process Linework coupled with important Civil 3D Survey resources of Figure Prefix Dbs and Style tools are a far better solution. Figure Prefix Dbs that are well-integrated with Description Keys Sets and Survey Query resources help a lot. The Framework supplies the resources and the Spreadsheet Tools to manage all of that. Who knew?
Process Linework works as effectively with resolved point data (point files) and with observation data (fbk). Ok. It does help to add a few Begin and End figure commands to raw point files to cut down on automatically generated spaghetti. You can do the fix edits in the Survey Db and then…
The Process Linework command appears in multiple places in the Survey Toolspace for important reasons. The reasons are not initially intuitively apparent. Do you want to process the original input, the edited, and/or specific results after edits?
Do More Collect Less
It is initially too easy to miss that Process Linework understands more Survey commands than appear in the Linework Code Set Style. See the Civil 3D help file links above. Field time is always more expensive than shop time. Judicious typical shop edits can be a very productive addition to just enough collection.
Old school code systems were almost all built to categorize the field stuff into Layer (or Level) CAD management systems. Let’s talk numeric code systems as an example (although alpha code systems do the same thing). You get groupings like the 80 stuff is all sanitary sewer stuff etc. Second, third, and even fourth digits get more specific. Maybe all the #1s are manholes (e.g. 81). But not all infrastructure pipe-like systems have manholes do they?
The Survey Codes system employed in all our Framework products is actually MODEL management based.
“What the heck does that mean?”
The kind of PART is more important to its initial field identification (or classification) than the TYPE of system the part is in. Simply – It’s a manhole, a vault, or a cabinet BEFORE you nail down the system. Yes. Everything we shoot is in a system.
This MODEL classification approach produces many fewer codes (much less to remember) and the ability to get more or less specific about stuff “on-demand”. We call this logic-based method - NOT Keys. It is based on the key information management data concept – it is often faster to identify what something is not than what it is specifically.
The same reality applies to Figures and their coding. As mentioned above in the list, we call that logic-based method BESTWay. You collect in generic terms with generic STRC keys and become more specific about the specific system of the Figures in the shop.
It never occurs to most people you can collect with one set of Survey Codes and actually employ a crafted Description Key Set to translate to another set of Codes. We supply a Survey Codes Spreadsheet Tool that allows you to perform this type of minor miracle.
Quality Controlled Data is Productive
Here’s a hint for civil engineering and survey firms that perform survey to produce design tasks. Certainly, a set of quality controlled Figures are necessary to produce a suitable existing surface and publication. We all get that.
What often gets missed is that a set of published figures crafted for design use often has huge man-hour benefits upstream on the design side. Roadway improvement projects are just one tangible example. Simply separating or connecting the figures into usable target “design” segments can be very productive. The data collected is one thing. Data engineered to be used and reused is something else again. An engineered copy of your Survey Db can become a handy tool and significant added value.