In the previous post we talked about some basic issues with Corridor annotation if we rely on Surface Features to generate the annotation. I even proposed a new Surface Group Label that referenced all forms of horizontal control.
In early AutoCAD Civil 3D versions the need to employ surface labels in corridor annotation wasn’t an issue at all. The surface labels were an independent Feature. They weren’t formally tied to any particular Surface. We could even pick locations beforehand and adjust the label reference the “right” surface later. Coupled with my proposed Surface Group label annotative life could have been easier.
There were objections.
"That’s My Job! What Am I going to do now?"
The ??? marks that appeared and plotted when references didn’t resolve correctly confused and scared people. People panicked. They corrupted their drawings. Users hooked the lost labels up to the wrong surfaces. Too much user and CAD manager whine went to the powers that be.
End of story. Maybe I should say,
The Beginning of Purgatory
On Horizontal Control
In the old days you could also reference ANY surface from an Alignment Group label. Along the way Autodesk has managed to kill this capability off too. We can create Label Styles that do reference Surfaces, but the connections are no longer exposed anywhere in the user interface. Arrrrgh!
Maybe this is a temporary setback, but we’re still waiting for the capability to come back.
An Alignment Surface Group Label with Incremental, Weeding, and Geopoint control specifics would solve the problem nicely. This is my favored solution as it has a lot more flexibility and is probably easier to manage in bigger projects. You can keep the control outside and label by reference.
It hasn’t happened yet.
Surface labels are man-hour problematic and Alignment Group Labels are non- functional.
We’re probably left with Point Features and therefore we must rely on the Corridor Point Output routine and interface.
The Point method is a snap shot –a specific publication of the specific corridor points you want at time A. I don’t know about you but I think we have to consider project related phases and time slices. A must for practical matters like multiple stake outs if you don’t work with GPS driven technology. A must if you must produce phased annotated grading plans for a project.
Chicken or Egg Annoyed
I for one was always a little annoyed that a Description Key Set that contained the potential point output from the stock Subassemblies wasn’t included in the out of the box AutoCAD Civil 3D. We had to do some of this work to produce our AASHTO compliant Assembly Sets for Intersections and the Jump Code Set Styles that work well for all 4 (four) things Code Set Styles are used for in Civil 3D.
I DO understand why.
Point Feature annotation of Corridor Features wasn’t the original plan. The dev team expected Surface Labels and/or Alignment Group Labels to do the job. Plans changed.
Even the point output from the corridor was a backstop fill-in solution for what users of older software might expect it to get from the corridor design Feature. Hence, publically we hear things like,
“Use Surface Labels”; “Use Station Offset labels”; and my favorite prevarication, “Why won’t you just give the contractor the finished surface model?”
Getting there is the issue.
I can guess at some other reasons why a Corridor output Description Key Set is avoided. The contents of this Description Key Set are subject to change without notice.
The actual Point Codes produced in a particular Assembly are a collection from the array of potential Subassemblies that a user might employ.
There is no summary documentation of the Point Codes for all the stock assemblies in any case. You have to root around and do real work with the real Subassembly tools to ferret out the truth.
I have to mentioned in posts that if you employ the Subassembly Composer in Civil 3D 2012 or 2013 you should use the published named Point Codes whenever possible. Why becomes apparent.
We actually had to spend more than a bit of research time to validate what Point Codes were actually in use in the 114 “stock” Subassemblies in Civil 3D 2013. The Subassembly code behind uses Point Code Index numbers not Point Code names after all.
What matters to Civil 3D users is how all of the magic resolves for us in the workday.
When we stomp on the gas we want GO - not excuses.
Build Your Own
One supposes the idea was a user would only make the Description Keys specific to the Assembly locations you wanted on a per-corridor or per-project approach. The number of Keys would be small enough for the folks and the organizations to handle. If you test this approach in simple corridors, this works. Therefore, this is Not a serious problem or issue. NOT! The real world is rarely simple.
Drag on the Dragster
Yes, the design capabilities and speed of design solution via corridor solutions are really there in Civil 3D. The Complex Corridors we must sometimes construct to deal with real-world, civil engineering and survey problems simply blow the doors off the above “build your own” approach and strategy. Practically at the user level Code Set and Description Key Set construction can’t be done…
On the Fly
Too much user knowledge of the specifics of all the many potential parts (many Subs are used only occasionally) makes this a potential man-hour fiscal cliff. It’s like driving a dragster without brakes and a parachute. A lot of smoke and speed and then bad things can happen.
The new InstantOn Basic and Jump Kit for AutoCAD Civil 3D 2013 will contain integrated Code Set Style and Description Key Set resources for all the 114 “stock” Subassemblies.
If you own and use IOB, you won’t be driving the dragster off the end of the track.
You won’t be blowing the engine or your brains out at the start line either.
The Whine and Roar - Corridor Point Output
The current Corridor Point Output routine is also a bit crippled as a potential annotative tool. It gotten a bit better lately, but it really isn’t optimized for the more complex task that Civil 3D history dumped upon it.
Corridor Point Annotation Wizard Wishes
- We can and do get huge Point Code lists. It’s usually not what we’re interested in anyway.
- There is no way to filter and pull corridor point locations based a selected Corridor surface.
As the designing user I’ve already determined what I think is the important data.
This is obviously one of the easiest to understand and best initial user starting points.
- We don’t have a simple method to sort Point Codes into natural left and right collections of points never mind by Subassembly Group.
Simply appending offset sides to the Point Codes would help a lot.
- Corridor generated Top and Datum Point Codes which are often the critical annotation are not available at all.
- The total Point Codes are offered up and there is no way to sort even by Assembly never mind Subassembly.
- While we can filter the output by Baseline but we cannot subdivide the problem by Region.
- We get only the hard coded Point Codes as point descriptions. We cannot get Descriptions based on the current Code Set Style.
The current Code Set Style could play a significant sorting role in this command’s interface. The odds are if you want it labeled in the Code Set, you probably want those same point codes exported and NOT everything else.
The odds are we are also probably very interested in locations on the Feature lines generated in the corridor by the current (or – God Forbid - a selected) Code Set Style and/or the Frequencies of the Regions. Maybe we might be interested at locations based only on Region Frequency and Targets.
- Output number range and/or named point assignment to Point Groups by Point Code would really come in handy.
- No “uncoded” points are offered up at all by any means. Some of these “uncoded” locations may be exactly the points we may occasionally need to annotate.
- There is no way to externally save all your choices so you can repeat the process again later successfully.
- Last but not least - we MUST output the point code locations to the current drawing. There is no support for direct output to a point file in any format. This drawing only method is often simply a waste of system resources and time. However, a 3D preview of the output would be really handy.
Whines, Wishes, and Wizards Aside
When it’s all said and done you can get the point locations out. You can manage and massage them into Point Group collections which can and will produce reasonable location Point labels. The end results can be canned into a separate publish annotation drawing(s) to label corridor point locations appropriately.
If you work from a systematic plan you can pretty quickly repeat the process on a new, changed, or even a different phase of the designed corridor.
Hint: you definitely want to have a Corridor Output Point numbering plan. Before you hop into the Corridor Point Output command you’ll have to try and ALWAYS remember to change the next point number in the Civil 3D Point Settings.
Why you can’t do this in the Point Output box mystifies me to no end.
The bad news…you still have to repeat the entire publishing process again if they move that stinking ditch again. The good news…