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

We examined in detail how we can take advantage of Civil 3D’s arcane methods of interpreting and resolving point data in a multiple post series on point display resolutions in AutoCAD Civil 3D. The topic of NOT Keys kept coming up. A couple of folks asked the basic question,

“What is a NOT Key?”

It might be a better question to ask why call it a NOT Key in the first place. Simply put - when we want to look for a needle in a haystack the easy thing is to first remove the hay. A needle is NOT hay.

What something is NOT is often the better way to define a search. Database search and sort geeks employ the logical NOT trick all the time because it is often the fastest to get to the smallest pile to search as fast as possible.

Where’s Waldo?

Do you want to search an entire airport parking lot for all cars, all SUVs, or only blue Chevy SUVs?
Needless to say if you are walking, it helps even more if you can be specific about the parking lot section and row number first.

If you can recall the section and row number you can employ inclusion for those exact details in your search. You also probably don’t need to search at all. The use of exact inclusion also may make you blind to the blue Chevy SUVs in the next row.

Logical NOTs typically solve search and sort problems faster when you cannot or don’t want to be exact in that final detail.

The Match Point in Civil 3D post includes the entire ACAD wildcard list employed by Civil 3D’s string parser. When we look for NOT in the wildcard list, the tilde ~ character jumps out at you. We combine it with a bracketed comma-delimited list to build a pattern.

What Does This Description Key Do?

MH[~ E,D,S,T]

The Key will match the two character MH pair and any other single character NOT in the list of "E","D","S", or "T".

  • MHU will match the key.
    So does MHX and MHF.
  • MHE and the other NOT list relatives are all ignored and passed over.
    In a word - they do NOT match.

Our manhole NOT Key allows us to BOTH match unknown manholes AND sewer manholes etc in a simple way.

I have to trust that I do NOT have to explain the obvious:

A NOT Key Never Works Alone

A Pattern List of 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

We get to be both specific and/or non-specific. We get multiple choice. We also additionally still get to have unique collection results based on what we do with the specific Description Key’s FORMAT property. For example: We can use a MHF key for communication manholes and still separate those from found MH manholes and more common MHD manholes.

An execution of a successful NOT Key strategy requires we have a pattern of related Keys that sort the results consistently.

Match Rules

We are responsible manage the patterns we employ within the constraints of Civil 3D’s matching rules.

  • The Descending order that the Keys are searched is fixed in the code
  • Civil 3D employs the classic Windows ASCII search order
  • Civil 3D returns only the first match

In the aforementioned points posts we addressed that we can rig the pattern match game for point data:

  • Description Key matches by employing multiple Description Key Sets and the Description Key Set Priority property.
  • Point Groups matches by employing multiple Point Groups and the Point Group Priority property.

The practical realities of Not Key patterns and the principals of the 80 20 Rule quickly manifest themselves into more productive results.

Key Disciplines and Standards

The usefulness of Keys and NOT Key patterns obviously extends itself beyond point resolutions into many other aspects in Civil 3D. The Framework for Civil 3D employs these principals delivered in easy to use Spreadsheet Tools to help you build more useful, flexible, and robust standards for Civil 3D.

In the field and existing conditions we discover and identify Parts in Structures in Systems. We identify it is a manhole, a vault, or a valve before we care what kind. In the office and proposed conditions we typically design and identify in the reverse pattern of System to Structure to Part specifics. This is particularly true in all model-based software like Civil 3D. These employ some form of System-Structure-Part structure in their object models by design.

The NCS Key Discipline Relates to Workflows post and other posts in that series details how these same issues related to our Layer systems and other BIM core information concepts.

Power of Names

In Civil 3D we also have lots of AutoCAD Styles and/or Tables that relate directly to this Key concept of Keys, Key-based Standards, and Key patterns. All of these familiar AutoCAD things require searchable and sortable names that hopefully are easy to recognize and don’t require lots of time to learn and maintain.

The 80 20 Rule applies yet again. Most of these keys are already agreed upon in national and international standards. You can download that Open Standards list of Civilized Keys here.

The logical NOT is very useful particularly when you have an ordered structured search process or when we need to separate named stuff into manageable piles. We do that a lot. The NOT is tangible drama…

To Be Data Centric or NOT to Be

The Keys and Format Tools in Civil 3D

Point Display Strategies in Civil 3D