Names, Names and More Names

With this post I am hoping to get some feedback as to what others are doing with all of the named items that MicroStation and InRoads now entails. I have been working with InRoads since its origins as TDP on the VAX. I believe its feature based DTM is the best idea for DTM's ever. But on a recent project, I have found myself overwhelmed with the requirements for template point names. Let me start with some background and my thoughts...

I was working at a mixed CADD shop when InRoads V8 was released and attended the first Forum after Bentley acquired the InRoads product line. I attended most of the InRoads sessions and spend a number of hours discussing the product with the development team members who were there. I picked their brains for as much information on the Feature based DTM as I could. Shortly thereafter, I began implementing a unified Feature Style system which given that there were two INI files and a FWF file to keep synchronized, was no small task.

A few years later, I was one of the participating consultant members of the V8 transition team for a local DOT. I and a few others brought a broad vision to the team, as we had extensive familiarity with AutoCAD. My firm, at the time was successfully using AutoCAD with LDD (now just LD) for land development work with a layering system of fewer than 300 total layers and most of that also was using bylayer with occasional "forced" colors or linestyles.

While we convinced that DOT that they did not have to go level happy and create thousands of levels, they did not see the benefit of bylevel. They did implement a modified version of the NCS level names - but their modification was one that I do not really agree with. They decided to eliminate the initial discipline character, feeling that the file the level was used in could handle that detail.

The DOT is an InRoads shop, but they have been dragging their feet on upgrading to more recent versions and to fully implementing a feature based DTM. So I have been forced to wing it on many of the names within InRoads. Having a free reign on this, I have tried more than a few approaches and have come to a number of opinions which I am now sharing and hoping for others to follow suit. Keep in mind, I am both setting these standards and using them in production, so there is always a method to my madness.

• Since I generally have many more features than levels, I don't believe in a one-to-one pairing of feature to level name.
• I do believe that, in general, a feature name should match the named symbology name. Although I have found, that in many cases, it actually takes a family of named symbologies to meet the needs of some feature styles. I also try to match Template Point names to feature names in a many-to-one pairing.
• Additionally, there are some feature styles that can have different names but share a common named symbology. Therefore the previous rule is not a hard and fast rule.
• I also loath underscores as part of these names as they require a shift key to type. In many drop-down lists, pressing a few keys is the fastest way to find a name and I found the use of the underscore often slowed down the process affecting the success of the search. As an additional benefit, dashes are shorter than underscores, which is a good lead in to the next item.
• I also think that brief, common abbreviations in the names is critical, since many of the dialog box items are of limited width. Relying on a tool tip, when it is even offered, can slow down the process. However, names cannot be too cryptic as to require a data dictionary to use it.
• As mentioned above, I try to base my Template Point names on the Feature Style names. This requires that you create a Point List with Styles to assist in naming and renaming points as the automatic point names result in names that I find are less than useful. I do not add every permutation of a point name to the point list, but concentrate on the top of grade points with and without their appropriate left or right designations. This allows the list to be used when building components and modifying templates.
• InRoads sorts many of the lists of these names automatically, so using common initial characters to group related names is, in my opinion, essential. This extends from feature names, named symbologies, point names to DTM features in surfaces.
• This same sorting issue leads me to believe that the use of the suffix for left and right items is better than a prefix. I have implemented -LT and -RT and with that approach, we have also added -M for items in the median area – this might be used when there is median curb features and outside curb features. We also added -F and -B for Front and Back of features that may appear twice on one side of a template, like sidewalk and trail edges. These always come before the left and right suffix.
• I’m not as young as I once was – some upper case letters are critical for those of us who have become visually challenged over the years. Using the MixedCase approach seems to improve legibility while preserving space.
• Verbose descriptions are useful to instruct end users of an items intended use.
• In general, every survey feature should have a corresponding surface feature. I can't imagine any reason to not have the survey and surface feature share their symbology. Many survey features also need some type of corresponding Coordinate Geometry feature. Control Points are one, but property corners are another.
• 99.9% of all surface features should have annotation enabled for plan, profile and cross sections.
• 100% of all surface features need some appropriate type of plan view display setting. (See next bullet.)
• Point features should display as points, linear features should display line segments and not points. There may be appropriate exceptions to these rules.
• For Cross Sections and Profiles, I enable Projected Segments, Crossing Point and Annotation for Linear Features. For Point Features, I enable Projected Points and Annotation. You never know when you may want or need to annotate a feature. I use Feature Filters to reduce the number of choices for commands using feature lists. With a sound naming convention, this is not difficult to setup.
• Even DNC, template points need to sometimes be displayed, I use a Sub- prefix as part of my subgrade template point names and assign the same styles to these points as their upstairs neighbor. Feature filters are used to prevent their display and interaction, as needed.
• My features styles for components are only for components. For rendering purposes, I create surface only components that can be used along all top of grade points. These are set to display in 3D/Plan view and optionally in cross section. For volumetric components, they are only set to display in Cross Section as I have not been able to see a need to display these 3D components in 3D as I have my top of grade surface components for 3D display.

I'm going to end this here to open it up for others to comment. But in closing, let me explain a little of why this topic seems to be worth throwing out here now.

As I mentioned in my beginning statement, I was working on a recent project and found myself running out of ideas for point names, even with all of my aforementioned "rules" - this real issue was that I had some complicated end conditions that required multiple branches to meet all of the design constraints. Also, as I was refining these end conditions and trying to meet deadlines, my "rules" seemed to get in my way.

I might have needed fewer point names if I had used many template drops, but as the design kept being revised, the problems with all of the template drops would have been just as big an issue. I literally have multiple ditches in multiple end conditions - as we needed to separate on-site runoff from off-site runoff. And sometimes one or both ditches used a vertical point control while other times they were 100% constrain driven. In some cases, two end conditions could share the same points, except for one point here or there that needed a different end condition properties. While this helped some with point names, it also adds complications.