Match Point in Civil 3D

Tags point, survey point, Description Key, figure prefix db, not keys, wildcard, CAD Standards

We wrapped up a previous post about the interpreted nature of point data in AutoCAD Civil 3D and the Civil 3D Point Display Priority Strategy with an argument that the Pareto principal, the famous 80 20 Rule, applies to our civil engineering and survey data. I argue, and most civil and survey folk would agree, that 20% of what we gather and create drives most of our project work.

As data-aware users of the Civil 3D data behind, we need to optimize our point work and workflows around the principal of Utility of Preference. Better code identification principals are mission critical Keys to more productive workflows and tools in civil engineering and survey work. The points of the puns are intended.

The Keys of Civil Dialects

Whether we recognize it or not, we tend to build our standards and meanings around the 20%. Our local dialect often becomes intensely personalized because our shorthand is so integral to our daily work. This is not so much about whether we say Kerb or Curb, but how we see and approach the data structures from field to finish.

As fate would have it back in the early days of Civil 3D I was lucky enough to have lots of access to lots of different organizational and company specifics and the personal experience in most of the entire food chain from survey to design to construction and even maintenance and GIS. Ok. I was, and still am, willing to ask and listen when most people could care less about what the people down the street are doing. I’m interested in the nuance particularly the nuances of patterns in the data.

The Power of Managed Meaning

The power of managed and integrated Style of AutoCAD Civil 3D data gives us all a shot at more adaptive standards and more productive tools. The Framework for Civil 3D must embrace Utility of Preference principals to perform for lots of kinds of customers.

The Search for Keys

As Amazon and Google have clearly taught us all – It helps to be able to search well especially when you can rig the game to favor results that benefit you more often than not.

In Civil 3D Land, this pretty much means we live in the world of ASCII search characters and patterns. What we call the wildcards. Our Utility of Preference based Survey Codes, Description Keys, Description Key Sets, Figure Prefixes, and Point Group definitions become optimized to the classic AutoCAD wildcards.

Civil 3D works with a find the FIRST match methodology driven by these forms of ASCII search.

There is a standard match behavior (or process) for Figures, Description Keys, and Point Group property definitions. Each interpreted match process works independently of the others.

Because we are often matching different details in the point data raw descriptions for Figures and Description Keys you can be fooled into thinking something else is going on. It is easy to get confused.

It is best to recall that all of the Civil 3D string interpreters or matchmakers are literalist bean counters. This is probably why most people just rely on only the most basic inclusive wildcard matchers – * (asterisk) or % (percent).

AutoCAD Wildcard Characters



# (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.

The website’s Members section also includes a separate page and link to this table. Register and get lots of free help for Civil 3D.

Figures Match the Words

Figures exactly match the group of 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 that the Figure generator – the Process Linework command - matches whole words not letters. Any wildcard character(s) that we want to employ must appear in the Figure Prefix definition ONLY at the end of the word. For example:

EP# or EP##

Most folks employ 0-9 numeric digits in either single digit or double digit patterns.
Odd and even last digits are used separate left and right figures.
The Prefixes themselves don’t look this way. I employed the numeric wildcard character just to clarify things.

When we say the Framework includes a Survey Codes and matching Figure Prefixes - we mean the Framework includes tools tuned to work together sometimes in packs of BESTWay figures.

The Framework includes the Spreadsheet Tools to create and manage integrated Figure Prefix Dbs outside of Civil 3D. We need a managed system for all the parts to keep the system in synch. Why?
Order matters. Preference matters.

Only the current Figure Prefix Dbs matters. There is no priority stack for Figure Prefix Dbs.

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 code and the second description string chunk specifics usually have to be pretty simple. For example TOC2 Begin, End, Start Curve, etc. This is a practical and field man-hour cost thing.

Data Can Be Improved

Back at the shack we 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 child figures for standard curb and gutter structures for example.

The NON-existence of a Figure Prefix match may be as important as the existence of one. What? Recall my words in the previous points 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. It is easier to edit that to create. A temporary or intermediate state of figures, like an intermediate design surface, can be a good thing.

Keys Match the Letters

Our Keys matter when point data enters a drawing. That said, in a pinch, the Apply Description Keys command will reprocess (albeit slowly) the point data a single point at a time and will do so on a Point Group basis.

A Description Key interprets the incoming RAW Description in a more detailed way. It looks at the first delimited chunk of the RAW string one letter at a time or character by character.

I like to say a Description Key matches letters not words. Description Keys can employ the more complex pattern and list matching wildcards. For example this list of Keys matches various manholes:

Manhole NOT Keys

  • MH
  • MH[~A,D,E,F,G,I,N,P,S,T,W]
  • MHA
  • MHD
  • MHDI
  • MHE
  • MHEL
  • MHF
  • MHG
  • MHNG
  • MHPH
  • MHS
  • MHSD
  • MHSS
  • MHT
  • MHW
  • MHWR

From the Many One

Like the Civil 3D Point Feature itself, there is really no such thing as a single Description Key in Civil 3D. As in the example above, the list of related manhole Keys actually work together to get us what we want and provide adaptive flexibility for both the field and the shop users. The principal of Utility of Preference at work.

When we say the Framework includes a couple of thousand Survey Codes and matching Keys - we also mean the Framework includes Keys that are also tuned to work together often in packs of NOT Keys.

The Framework includes the Spreadsheet Tools to change that system and manage all the parts to keep the system in synch. Why? Order matters. Preference matters.

In Civil 3D we can also have a stack of multiple Description Key Sets to search down through.
The current Description Key Set Priority property matters and affects results.
In a previous Civil 3D Point Display Override Strategy post we discussed the practical use of one or two large Description Key Sets.

Play the Slots

In the old Land Desktop days, we played the Description Key slot machine on potentially two machines. Most people and organizations really only used one. LDT Description Keys really do not do the same thing as a Civil 3D Description Keys in spite of the use of the same old name and some other overt similarities.

In Civil 3D, we can play a whole row of Description Key slot machines all at once. You can 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 priority capability in Civil 3D that was not even there in the old software.

The Civil 3D Point Display Priority Strategy requires that you consciously reorder the Description Key Priority stack order and understand how and when to Insert Points, Remove points, Update Point Groups and Apply Description Keys. These commands are obviously not at all the same thing. No. I did not miss Import COGO Points. I think COGO points are usually a bad idea given the capabilities and speed of Survey points and Survey Dbs.

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. 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. Needless to say the Framework resources include these and the managed system tools to edit, create, and maintain them.

Wilder and Wider Survey Queries

Survey Queries which should employ the same Codes and Keys must obey the different (and simpler?) SQL wildcard syntax for large text searches. The Civil 3D Survey Query Essentials post covers the substantive differences and syntax details.

The Third Level of Match Magic

Remember that the Format column in a Description Key can change specific chunks in the RAW description in some interesting and useful ways. See the To Format in Civil 3D Description Keys post for more on this. Yes. You can use the Format column to annotate (label) this way or that way, but there’s more potential powerful interpreter magic here.

The Description Key Translator

Consider that a matched Description Key Set can change the meaning of some of the incoming Point data in a single pass. We can specifically enrich the point data with planned a step by step process – aka a workflow. Specifically:

  • Apply one Description Key Set and change the interpreted point data.
  • What you do with a secondary pass is a matter of planned intent.

For example - systematically generate offset figures from the classic Top of Curve example. This requires a couple of well-designed Description Key Sets with unique Format details for the task at hand.

  1. Collect all the right and left TOC shots.
  2. Export them to a new points file
  3. Import that to a Survey Db
  4. For all the right side TOC apply this Format
  5. For all the left side TOC apply that Format
    All of that is new and improved data.
  6. Reprocess the newly formed point data to generate the new offset child figures.

There are other ways to get this done in ASCII text editors and even with Civil 3D Feature tools in drawings and/or Survey Dbs. The level of consistency and audit capability you need might be more difficult to attain with those methods. We are left with the dramatic choice…

To Be Data Centric or Not to Be

Point Display Strategies in Civil 3D

The Keys and Format Tools in Civil 3D