The NCS Layer Standards rely on the concept and practice of a standard Pattern (Keys and delimiters) coupled with Major and Minor Keys. Every CAD Layer or Level standard employs this basic concept these days. True, we could just employ the unique numeric IDs the software’s actually use, but these aren’t very user friendly. We walked away for good human reasons.
Last time we talked about seeing the Standard Keys in three shades.
- Discipline Keys
- Software Keys
- Organizational Keys
We talked some about Discipline Keys in the previous post. This post continues that chat. There are subtleties worth talking about since the Discipline Keys are the most significant keys for most of us.
Sentence or Word?
We tend to talk about the entire or resolved Layer Name. When we’re using them we deal with the whole like it was an entire sentence of meaning. There is an interesting mental back and forth we employ here.
We read layer names both left to right and right to left depending on what we’re doing - what we care about at the moment.
- C-ROAD-CURB-TEXT tells us were dealing with a Label that relates to a CURB structure in a ROAD system that’s design proposed. We might read the Layer Name this way when we have to put in the labels or sort them out into the classification the Layer name provides.
We think Inside out. - When we have a filtering or sorting task to perform, like when we perform a publish process, we tend to read and filter things in the left to right direction.
We think Outside in.
Back and forth coherency of your Keys should be tested.
There is built in interpretation and assumption implied in the layer name sentence. This is a human thing whether you tend to be a literalist about the specific meaning of a Key or not. Our brains squish things into associative symbolic personal and social representations automatically. The heuristic practically speeds our decision making. Whether we like it or not, we get to live with the outcomes of how we think about things. Back in the real world:
- A contractor must interpret your design drawing differently than you do.
- He must be concerned more with build process optimization.
- His costs and survival are directly linked to that.
This is also a reason why a regular position of the codes in the Pattern is important to us at a productivity level. If the same Key code moves position a lot, the standard tends to create more confusion and uncertainty. Yes. It is also harder to read and sort.
Hence we tend to end up with the creatures of the NCS Majors and Minors whether you like the NCS specifics or not.
We tend to internally battle endlessly with Layer Standards that are built without a consistent syntax and testing against syntax rules – i.e. The Key position arrangement in the Pattern and/or inconsistent meanings of individual Keys.
Show Me the Money
The value and substance of the Layer Name Sentence is formed in the agreed on consistent Meanings of the Keys in a consistent Pattern.
I consider this to be the second most important thing about standards.
We Reprise Oxymorons
We all do this. It is easy to create NCS Layer Names (or any names for that matter) that mean something - C-NODE-CURB that we “understand” in both CAD and real world terms. However, these Layer names may actually be oxymorons – words the really don’t go together in the larger context and do not really support the practical reason for the standard in the first place.
Perhaps we can all agree a NODE (point) is always a smaller part of a larger Structure or System. We may want to make NODE a Major Key because point data seems important to our (or someone’s) current tasks and workflows, but like I said in the previous post:
There is Nothing Unimportant About a Minor Key
Personally and practically engineering disciplines need Major and Minor Keys that do not appear in the AIA NCS Standards where the work and workflow of the discipline requires them. (Back to the first law of standards.)
- These “new” Keys should not conflict with the official NCS Key meanings
- Don’t substitute new Major Keys for the agreed – STRT for ROAD or DIRT for SITE.
- Don’t mess with the Keys outside of your discipline.
This is the reason why some civil/survey people don’t like the NCS –
the architects messing with how they think we work. - Keys should focus on the SYSTEM>STRUCTURE>PART>CLASSIFATION pattern
Field Set Language and Plan Set Language
Civil engineering and survey professionals seem to prefer Standard Keys that reflect the real world systems and structures they deal with in what I like to call their field language. This works like the Plan Set Languages (symbol systems for example) change as we flip through a project’s plan set. I talked about Plan Set Languages before if you missed the drift here.
Our Open Standard Keys reflect this practical bias. We built them with comparative heuristics.
My Way or the Highway
There is some variance in Key term in various locales, but most folks understand quickly what the other guy says or means. Some argue to some extent key preference and meaning is regional. Maybe this is true.
I ask WHY?
At least to me, this is not so regional factor as it is an organizational influence and bias issue.
Hence I’ll talk about this factor in regards to Organizational Keys in another post.
The SYSTEM>STRUCTURE>PART>CLASSIFATION pattern and position of Keys in the NCS and all layer and/or level naming standards has evolved over time. These changes also reflect the improved automated drafting technologies and more powerful computer performance capabilities of today.
If we start a discussion about System and Software Keys, we do have to ask the question…
Will the NCS Survive in Model World?
We recognize that model based software already includes the SYSTEM>STRUCTURE>PART construction, requisite parent-child(ren) relationships in the built-in object and feature definitions, and rules and processes to manage them. For example:
- An alignment in Civil 3D only “needs” a layer to display itself because it now does that via a style (an abstraction) that references AutoCAD layer names for the representation of its components.
- The alignment Feature (the data, rules, order, etc.) can exist comfortably without an AutoCAD display layer for the parts.
- An Infraworks alignment can be the same and just differ by how it is represented and graphically manipulated in that software.
We can safely bet that the development of apps or “the appification” of Features (collections of objects into representative SYSTEMs) will continue and expand in the future.
The Wonder of Publish on Demand
The NCS will survive. It in fact seems to be thriving because it is a standardized publication specification. The NCS and related standards are not intended to be a model storage engine. They are intentionally not vendor specific.
The whole CAD standards issue is not such a big deal if we implement forms of Publish on demand and pay attention to the development of those internal processes. What appears to be more work becomes less.
Our Production Solution products provide the basic spreadsheet and script generation tools to let you work and publish in any Layer Standard. If we employ software like AutoCAD Civil 3D, we are much more able to craft an output to the needs of the end customer. We are not so confined to produce in the standards that we deliver in.
The ability and capacity to perform this feat is vitally important in design professional organizations of any size. Today it is a competitive advantage. Tomorrow it will be an organizational necessity.
Model Based Rocks
So let’s talk more about how we can stay off the reef in the NCS.
Next time Software Keys and the NCS.
As you may recall,
We have to work out how to control our mushy apps along with our flabby abs.