Shall we continue to explore the interpreted nature of point data in AutoCAD Civil 3D? In the last post we talked about the Point Display Override Strategy. That’s where many civil engineers and surveyors end up after initially struggling with AutoCAD Civil 3D point display issues for a bit.
If we employ the Point Display Override Strategy, we choose to interpret the point data basically one way. A survey code always means the same things and will produce the same results. Sounds good.
Interpret This Data
The Override Strategy works well. It produces consistent symbols and annotation and mostly keeps new Civil 3D users happy. We need a single set of codes with matched Keys in a couple of Description Key Sets. The Point Group definitions we use are pretty static and have a fairly fixed order targeted at classic plan set publication specifics. A systematic method to Standardize Point Groups helps.
However, because the Override Strategy does EXACTLY those things, we also soon discover it often has hidden (and unspoken) back side to it. There is a high probability that too many production man-hours will be invested in point display and label maintenance on an individual point basis.
A significant reduction in that manual annotation burden is a big part what Civil 3D is supposed to do. If we can systematically limit that man-hour duplication and waste, the work and profit could be better.
If you’re a high performance person or you’re just lazy like me, we look for another approach. We can employ the interpreted and flexible nature of point data to our benefit. This requires both thinking and working differently.
The Point Priority Strategy
Back in the day I also called the Point Priority Strategy - the Point Director Strategy.
I find that the metaphor of a movie director often makes sense to help better explain the challenges of Civil 3D point resolutions. This take reflects the more dynamic publish on demand and BIM realities of modern civil engineering and survey practice. Everyone wants it their way.
Work the Same and Publish on Demand
As the Director we have a Script, Cameras, a Set, and a group of Actors we need to get to work together to produce specific Scenes to communicate the important data on a limited man-hour budget. No doubt. There’s an art to the work.
- We can costume the Actors in the Point Styles we want
- We may supply the Actors with Point Label Style – the lines to read (or not)
- The Script – the point data behind, remains editable and malleable to some degree
Needless to say some audit process on changes is certainly important.
- The Actors appear in the Scene – the other Civil 3D and AutoCAD stuff that provides the larger context
- The Actors also work on a Set
In the context of interpreted point data – the Set always means Description Keys in multiple Sets with a priority order and related Point Groups with a priority order.
- Since Civil 3D is AutoCAD there is always a Camera with a perspective and therefore a scale involved.
To clarify how fundamental that is:
Select nothing in Civil 3D.
What is displayed in the AutoCAD Properties box?
Rule the Points
Whether we like it or not, we also have to deal with a couple of Unions whose current priorities and rules always affect how the Actors and the other parts and pieces perform on screen. Description Key Set priority and Point Group priority always matter whether we pay attention or not.
By now I trust you recognize that somehow you have to tell Civil 3D to Update, Refresh, Rebuild, Synch, etc. the data behind. The software will resolve any Union disputes for you, but as a Civil 3D user you are responsible to create both structure and order for that.
We must call the shots or the Civil 3D diva will.
Mistakes can be edited out in post-production edits, but getting the Scene right in as few takes as possible benefits everyone. The good news is the Point Priority Strategy when employed in Civil 3D says we can get to a suitable result by iterations much faster.
If we want it Done in One, we miss the point and benefit of Civil 3D.
What I See is What I Want
We can get more display flexibility. Alignment based Point Groups are a good example. You are responsible to know what you want and how you want it to appear right now. This also requires you understand how to make that happen inside the Civil 3D interface.
The Point Director approach makes sense to those who have to perform the process of point QAQC, figure edits and creation, and surface create and edit QA work. In each of these distinct tasks it helps to have the point Actors look and, at times, speak their lines (the Labels) differently.
Practically, that means you will require prepared resources.
Is work on more productive prepared resources in the real job with long-term benefits?
I should mention that if you only see the published final results (like many a principal or project manager) the need for this other display representation and Style tools inside Civil 3D isn’t initially apparent. To clarify:
“Boss, we’re going after the lost, hidden, and in-process man-hours.”
Any Project Manager who is watching Civil 3D project and model development man-hours should appreciate that proactive reality.
The Point Priority approach says the point data remains DATA as long as possible.
- How I need to display the data NOW is more important than any downstream publish goal.
- I care that the point data looks this way NOW because I want to QA and FIX the data and improve the usefulness of the Civil 3D Features that the data produces.
- I choose to consciously ignore any published end result until THAT published result is the specific task at hand.
- Publish specifics will quickly become easier because I understand HOW to get any other point display result.
Sometimes I neglect to mention the fact that TOO MUCH information is often as dangerous as TOO LITTLE immediate information to the user. The Civil 3D skill and ability to identify and quickly isolate the important data in a sea of data is where the rubber hits the road.
Let’s keep the WMTI problem in mind as we explore some generic details.
Point Director or Point Priority Strategy Specifics
We will always have multiple Description Key Sets. Some Description Key Sets may be in your templates. Some Description Key Sets you may load on demand (like character actors) from other drawings, style library drawings, or other template or project drawing files when you need them. What is said about Description Key Sets applies inescapably to related Point Groups sets.
- We may think of the Set or really the stack of Sets as Task-based
Perhaps Purpose-based would a better formal term.
- I have ALTA survey data. Load those Sets.
I have survey data from an oil field. Load another Set(s).
I have a commercial site development parcel data set. Load that one.
I have survey data from a contractor I need translated to our company standard. Load that one.
- We will play with the Sets content and Priority orders to maximize QAQC identification and our point display resolutions.
You get the idea. This point work is much harder to accomplish with classic imported COGO points than Survey DB points and Survey functionality.
We Lust to Over Specialize
Could we build specific task or purpose-based Civil 3D templates to handle the tasks?
Of course, but then we have to be careful to make sure we don’t create for ourselves and our organization a Civil 3D Style and Civil 3D Template maintenance issue.
These tend to happen fast because of the interrelated, referenced, and integrated way Civil 3D handles the Style and Label Style properties. Small differences in Style tool property values and even tool names easily create maintenance challenges.
Dealing with the differences and exceptions requires we spend time checking that the integrations between the variety of moving parts: Description Key Sets, Figure Prefix Db, Point Groups, Style collections, etc. all work in multiple scenarios.
We have a lot of EXACT NAMES to keep track of and then MATCH appropriately. Sorry folks. That’s the way it is. Both the Style and the data need to be managed.
Data Management Development
The essential data management problem is really not rocket science or all that hard. It is, however, something new to most CAD folks particularly at the level of complexity happening inside Civil 3D. It does require attention to detail, a plan, and systematic execution.
Most Civil 3D users want to blame the Civil 3D detail when the lack of a real plan and haphazard execution are often the more applicable issues.
AutoCAD Civil 3D is decent about moving around and updating the Style tools and resources you’ve got. Civil 3D is not very good at helping us create and manage itself and/or the development at the fundamental levels. That’s why all Framework products employ and include a development project with data.
Without the specific data behind - specific Style is meaningless.
Systematic Framework Customization
We will have to employ external resources like Excel files (or databases) to help you Plan, Do or execute, Check, and then Act (PDCA) to maintain the point stuff. Excel works fine. You’ll have to keep doing a consistent continuous development process loop as things change. Why we supply and employ the Framework Spreadsheet Tools to do this.
That sounds a bit intimidating especially after trying to do it the first time.
Remember – it is data.
80 to 95% of the stuff and specifics for all the varieties of integrations never change.
The 80 20 Rule Applies
We are initially in search of the Similar not the differences and/or exceptions. From a big master list of Keys (or codes) and multiple descriptions (Formats) come all the published special parts – Description Key Sets, a smaller number of Figure Prefix Dbs, and Point Groups.
We shouldn’t have to reinvent the wheel to employ Civil 3D point data successfully. After more than ten releases of Civil 3D that would be dumb.