Last post we talked about basic tracking tools like User accountability, Autodesk Design Review, and employment of the Feature Description fields in AutoCAD Civil 3D and how they apply to QA tracking. Here’s how to employ AutoCAD Civil 3D COGO Point Features for QA/QC and fix tracking.
This works well in AutoCAD Civil 3D 2012 and AutoCAD Civil 3D 2013+. In older releases this works, but you have more limitations. Survey functionality took a big leap forward in 2012+.
Tracking edits and changes by COGO and Survey points works thanks to the unique features of Civil 3D and the external and sharable Survey Db.
Point By Point Tracking
A Plan and A Process
To employ points as tracking objects takes a plan and a ritualized process.
There’s a tiny bit of upfront work that can be continually improved on without undue man-hour work or geek-like Civil 3D user skill. Everyone can appreciate the no brainer and the KISS of this method.
Decide from the Plan and Build the Collector(s)
You set aside a range(s) of “project” COGO points as “QA” points.
You do have a “standard” project plan for point numbering don’t you? Of course you do - Silly me.
In InstantOn Basic we even include one of these and the “default” named Point Groups to help begin your COGO point management scheme. These are documented in BOTH the template drawings’ Point Group properties and in the external Jump Standards Documentation included in every product download from us. We even supply some external resource text files for user tweaking and updating of the Point Group definitions.
Here’s a post on how that works.
In any case, anyone can easily tweak the built in IOB Point Groups to your own internal specs and point numbering plan in a few minutes without delving into the more sophisticated stuff. That’s there when you do need it. We know…
It’s Easier to Edit than to Create
So now you’ve got a point range and a Point Group collector (the COGO point display engine) for your tracking stuff - This takes a minute or two of setup. I’ll often assign a Point Style to the QA Point Group that employs a relatively sizing Marker so the QA points auto-size to my zoon level on my REGEN command.
Description Key Set Priority Adds Gusto
You should build a basic DescKeySet that translates some simple to input codes into bigger standard explanations via the Format field property. For example: “QP” in raw formats to “Point bad”.
As you can see this QA Key set employs a simple Key Naming rule. All QA points begin with the “Q” character.
To start out doing Survey QA tracking you really only need 4-5 keys: QC (control), QP(points), QF(figures), QS(surface), and QFX(fixed). Ok.
We’re maybe 5-10 minutes of upfront investment time.
Remember to move this QA DescKeySet to the top of the Description Key Set Priority stack before you begin to slam in the marked errors and/or edit them into fixes.
Get Ready to Run
Set your next CURRENT point number into the QA point range.
Even if you FORGET and blow the range in Civil 3D you can adjust the numbering of the tracking “QA” points at any time.
Here we’re using a default elevation for the QA point set above the highest surface elevation.
By now you’ve discovered that the Civil 3D Layout toolbars are modal. If you change the Point Settings, create points, and then close the Points Layout toolbar those changes (like Point identity) reload from the command settings.
About the only serious thing you have to worry about is forgetting that and accidentally stitching the QA points into point number holes within your existing Survey point data range.
Civil 3D will even let you deal with this nasty with exceptional grace – if you know and play by the simple rules.
It’s NOT a Survey Point
Even if you accidentally do put points into your survey data point range, you can fix even that if your imported points are from an attached Survey Db.
You always put ALL your imported points into a Survey Db don’t you? You don’t?
The old school Import Point method works, but you’ll work harder.
That’s not my favorite thing.
If you’ve been Civil 3D smart and used a Survey Db, Remove all the Survey Points from the drawing.
What points that are left the drawing will be only your QA points because they are COGO points not Survey points.
The concept of NOT is a useful thing.
Make an Assessment pass of your imported Survey data
Find a problem - put in a point with a manual description. You can be detailed about things in the point descriptions after the first Key characters just employ your standard description divider character (a space character) and slam away.
Of course you can first use super simple two letter Keys and get fancier and more detailed with practice. You also NEVER find all the issues in a pass. This is data cleanup after all. The idea is to build a more permanent To Do List record and add to it.
I’ll often copy paste in the more complex QA point descriptions from a standard text file or better yet the spreadsheet cells from a QA documentation spreadsheet. This saves me User typing time and tends to improve both the meaning and the depth of coverage of QA tracking.
You don’t have to.
How do you document internal QA standards? I think ALL documentation should reduce user time and effort on the job in the real world tasks or it’s often wasted effort.
Call it “Dynamic Documentation”
The concept of Dynamic Documentation is simple - keep reusing the work anyone in the organization does. Make the documentation as transparent to user need as possible.
Teach your people to actively participate in the day to day continuous improvement.
Throw away what doesn’t work no matter how sexy it first appeared.
Try again until it works for real people doing real work.
Use is The Metric that Matters
Next time some practical tips on how to employ QA tracking using COGO points and how to expose all of the ever-changing tracking results to everyone with access to the Survey Db.
Links to all the posts in the Track By Point series:
Track Civil 3D Data Edits in Survey and Beyond