Jump Kit

The Framework for Civil 3D
Get More

Templates Only

See The Framework Work
Get More

Become a Member

Master Civil 3D
Get More

Autodesk Civil Videos

Free Civil 3D Training
Get More

Framework Videos

Free Civil 3D Videos
Get More

This is the fourth post in a series about Point Display Strategies and Tactics in AutoCAD Civil 3D.

Point Display Strategies - Part 1
Two Paths Out of the Woods - Part 2
The Point Director Method - Part 3
Point to My Match in Civil 3D - Part 4

A Host of Matchmakers at Work

Civil 3D works with a find the FIRST match methodology driven by ASCII search order and the now ACAD classic “wildcard” characters and patterns.

AutoCAD Wildcard Characters

Wildcard

Description

# (pound)

Matches any numeric digit.

@ (at)

Matches any alphabetic character.

. (period)

Matches any nonalphanumeric character.

* (asterisk) or % (percent)

Matches any string, including the null string. It can be used at the beginning, middle, or end of a string.

? (question mark)

Matches any single character.

~ (tilde)

Matches anything but the next pattern.

[ ] (brackets)

Matches any one of the characters enclosed.

[~ ] (tilde and brackets)

Matches any character not enclosed.

- (hyphen)

Specifies a range for a single character when inside brackets.

' (reverse quote)

Escape character; reads the next character literally.

, (comma)

Enters a set when used between items.

There is a match behavior (or process) for Description Keys, Figures and Point Group property definitions. You can toss in the new Survey Queries in AutoCAD Civil 3D 2013+ too.
Each “match” process works independently of the others.
Because we are often matching different details in point data raw descriptions for Desc Keys and Figures you can be fooled into thinking something else is going on. It is easy to get confused.
I know I do sometimes.
Just remember that ALL of the string matchmakers are literalist bean counters.

Figures Match the Words

Figures exactly MATCH the first characters up to the first string delimiter (like a space) in the incoming RAW Description to add into the ordered pile of point locations that connects the dots.

I like to say the Figure generator matches “whole words” not letters.
In the example above we're expecting that all the figures will employ two digit line codes and the highest figure "name" employed will be "09". We could have used the "#" to embrace all ranges of two digit line codes. Would that also match one digit line codes?
There is no priority stack for Figure Prefix Dbs.
Only ONE Figure Prefix Db can be CURRENT when you “Process linework”.

The Figure generator looks for list of specific “command” character matches from the CURRENT Code Set Style in the next delimited chunk of string and usually ignores everything else.

Out in the field during collection the second description string chunk specifics usually have to be pretty simple. For example Begin, End, Start Curve, etc. This is a practical and field man-hour expense thing.
Back at the shack you can post process that second string chunk in the point data in more detail. You can tweak this second chunk for specific Figure points to automatically create offset sub figures for standard curb and gutter structures for example.

The NON-existence of a Figure Prefix match is as important as the existence of one. Huh?
Remember my words in the last post about WTMI.
Maybe you only want to check and edit roadway surface figures now. Therefore, more than one Figure Prefix Db can come in very handy when you need some but NOT all figures generated.

Keys Match the Letters

Description Keys looks at the SAME incoming RAW Description in a more detailed way. It looks at the first delimited chunk of the RAW string character by character one at a time.
I like to say the Description Key generator matches “letters” not words.
Hence you can have a stack of sets of Description Keys to search down through and so priority matters and affects the CURRENT results.

Play the Slots

In the old Land Desktop days, we played the Desc KEY slot machine on potentially two machines – to be honest most people and organizations really only used one.

In Civil 3D we can play a whole row of Key slot machines all at once.
You can obviously increase the odds of a “correct” (or “incorrect”) match jackpot this way.

In other words, you can rig the ORDER of the matching game to get what you want NOW by employing this built-in capability in Civil 3D that was not there in older software.

This requires that you consciously reorder the Description Key Priority stack order and understand how and when to both Update Point Groups and Apply Description Keys.
Update and Apply Keys are obviously not at all the same thing.

Civil 3D is a diva.
Remember that the context hierarchy in the Toolspace (where and when you are clicking) almost always matters.

The Unseen Matters More

Many new Civil 3D new users complain that there is more data management in Civil 3D.
Oh Yeah. Some new data/information management skills are certainly required.

Maybe Civil 3D user productivity is more about managing what you don’t see than what is visible on the screen?

Not Keys

This post (and a follow up) which is all about “Not Keys” clarifies one significant way that you can add more detail to your field and internal QA via an inventive use of Description Key specifics without working harder. This wildcard effect is accomplished via an information technology method that works very well inside the data centric Civil 3D model.

In the Not Key example shown above we absolutely match the two character "MH"; ignore a range of three letter code begining with "MH" for a range of selected character; then match the previously "noted" characters.
In the field we can make the third character an "X" as in "MHX" if we have no idea (or don't care) what type of manhole it is. Note that "MHA" does the same thing. 
"MHX" will route the point to a general utility layer in the NCS format as assign a generic Manhole Point Style.
An "MHE" gets us what?

Not Keys Work Together

The whole range of matched and unmatched keys work together to allow us to be BOTH specific or NOT depending on need and circumstance.
If we add a "X" to the MH not key above, we could also force MHX to never match anything. In effect MHX becomes an unrecognized and uncoded point.
Maybe that reminds us to find out what kind of manhole it is back in the office.

For some folks the Not Keys concept creates the “Ah Hah” moment.
Field people almost all like the results and simplicity this stacked approach offers.
That speaks volumes for its day to day usefulness on a practical level.
People tend to prefer consistent rules over detailed specifics.

The Not in Point Groups

If your people bone up and understand the Not Keys concept, they can also employ the same basic concepts to Point Group construction and thereby their on-going “point display” maintenance practice.
One new basic data management skill pays off in multiple ways and on multiple days. Way Cool.

Point Display Management by Point Groups

A managed point display by Point Groups requires more understanding of the whole process and a more rigorous and structured application of the available Civil 3D tools.
For the most part, typical point data (which varies a lot by survey data “flavor”) can be “grouped” very effectively inside Civil 3D. Even our InstantOn Basic templates have NCS "like" Point Groups that help you do that.
Once similar point data is collected, it is much easier to be specific and detailed (or NOT) about how you want the point data to appear.

The Desc Key Serial “Language” Translator

Remember that the “Format” column in a Description Key can change specific chunks in the RAW description in some interesting and useful ways. Yes. you can use it annotate (label) this way or that way, but there’s more.

Consider that an Applied Description Key Set can change the meaning of some of the incoming Point data in a single pass.
You can specifically “enrich” the point data with planned a step by step process.
Specifically you can Apply one Key Set a change the point data.
What you do with a secondary pass is a matter of planned intent.
For example - systematically generate offset figures is a classic example I mentioned earlier. Collect all the right and left TOC shots. For all the right side TOC apply this Format change. For all the left side TOC apply that Format change. All of that is “new” data.
Reprocess the newly “adjusted” point data to generate the new offset figures.

“How would you like that labeled, Sir?”

To Be Data Centric or Not to Be

The Point Director|Priority method is a more data centric approach to the Civil 3D point display challenge. It requires more planned integration and more structured processes. It requires users who have developed deeper data management skills inside Civil 3D.

The Point Director method isn’t always necessary. However, it also easily embraces and includes the previously discussed and more classic Override Method without batting an eye.
Like I said in the first post of this series -there are always a lot of ways to get it done.
What we learn getting there may be the more important thing.

As in many Civil 3D cases…

The Two Paths Lead to the Same Place