InstantOn…

"/>

I Give Up... What's a NOT Key?

Tags Description Key, Description Key Set, figure prefix db, not keys, survey point, COGO points, survey

We're hard at work wrapping up the packaging for a new Jump 4 InstantOn Survey product. A bunch of people asked for it. 
They think a huge set of preconfigured Description Keys, a Description Key Set collection, with linked Point Styles (based on known National Standards), the matching Figure Prefixes, Figure Styles, etc might be of use to a few organizations. Do You? We'd like to know.

Find The Key

Civil 3D adoption can stop right at your own front door. You know this scene. You're standing on the stoop with arms full of stuff trying to unlock the front door. You have your wife's key chain with a wad of unfamiliar keys. Does a high school janitor have fewer keys than a soccer mom? Is this mace of keys her secret weapon of self defense?  All of the keys look exactly the same thanks to the local hardware superstore where she copied them.

"Here Honey. Let me get that for you. It's the third one in from the Olympic panda."

Our Description Keys are all too often just like that. In LDT our Keys worked. Maybe they weren't all that fancy (Who understands how the strings are really matched except for geeks?) but we went out and the data came back and somehow it became a drawing.

Then Civil 3D came along. Oh No. On the surface things look pretty much the same and even have the same names, but Civil 3D doesn't work the same. Point Features are certainly not blocks with attributes and Keys do More than send scaled AutoCAD blocks to layers.

Good News! The Song Remains The Same

The String parser that matches your Keys works the same as it always did. All those dusty and trusty AutoCAD wildcards are still honored. They do their ASCII matching thing. But do you use them well? I mean do you use your Keys to their maximum potential?

What Does This Key Do?

MH[~ E,D,S,T]

The Key will match MH and any other single character except "E","D","S", or "T". MHU matches and so does MHX, MHC. MHE and its list relatives are all ignored and passed over. They do NOT match.  

This is a NOT Key.  Why do we call it THAT? Simply put - when you look for a needle in a haystack the simple thing is to remove all the hay first. What something is NOT is often the fastest way to find a practical real world solution. Database people use the NOT "trick" all the time. How did you find THAT on Amazon?

Odds are You use NOT a Lot 

NOT is very useful particularly when you have an ordered structured search process. THAT is exactly what is happening when we talk Description Keys, Description Key Sets, and their drawing specific Priority Stack property.

Our manhole NOT Key allows us to BOTH match unknown manholes AND sewer manholes etc in a simple way. We get to be both specific and/or non-specific AND we still get to have unique collection results based on what we do with the FORMAT property.
For example: We can use MHC for communication manholes and still separate those from found MHU manholes and our more common MHD manholes.

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

A NOT Key Never Works Alone

Since I've ventured into String theory (just a little), I'd like to point out that really smart people can spend way to much time looking for the exactly wrong thing. The expectation of a result is a powerful thing.
Physicists looked for the wrong kind of light in the universe for the better part of 50 years before discovering their error only recently. Dooh!
US intelligence looked for Osama for a decade where he was NOT. Dooh!
The question was NOT, "Where would a terrorist hide?" It was, "Where would a millionaire who the son of a billionaire hide?"