Thoughts on Names within InRoads - Please Add your own Thoughts

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.

  • For all the Open Roads users, the Names of SELECTseries 2 carries forward into SELECTseries4. So the idea of point, component, style and named symbology naming convention still applies. In fact, it really needs to carry forward into Element Templates and more.

    I also see that in the Model Properties dialog box, you can rename models and assign a default description and logical name that will be used when a file is referenced into other files. On large projects with many users, this makes working with others files much easier. When setting up a file, you may reference in many files created by others and not return to the file for day, weeks or longer. If the descriptions and logical names automatically are filled in with useful information, that delayed return to the file will be less mysterious if it is necessary to manipulate reference files.

  • Caddcop,

    I generally agree with your naming approach and degree of organization.  Naming conventions provide for user and administrative efficiency, and apparently in some cases can facilitate more functionality in the software itself.  Therefore developing naming conventions is not an option, but a necessity.  It is desirable to have these conventions simultaneously satisfy multiple criteria:  

    * Names are meaningful, easy to read and understand.  

    * Names facilitate some sort logical grouping of similar items.  

    * Convention is expandable and able to support the addition of new names.  

    * Convention provides for needs but is not more complicated than necessary.  

    Per your discussion, I can see that this really takes shape when setting up InRoads functionality.  See my outline regarding the Developing Preferences for InRoads, in which you provided valuable input.


    As I have explored the topic of developing Preferences, with the help of recommendations and commentary, my thoughts are directed to the need for CAD Standards, Workflow, and Best Practices.  Here is my stab at defining a process for developing InRoads Preferences:

    1) Define Standard Level Names and Attributes.  

    2) Define Standard Text and Text Attributes.  

    3) Establish Standard Symbols and/or Cell Libraries.  

    4) Create Named Symbology CSV spreadsheet file (Microsoft Excel).  

    a) Define Naming Convention for Named Symbology names and descriptions.  

    b) Incorporate Standard Level, Text, Symbols, Cells, and associated attributes.  

    c) Apply standards to applicable Default, Plan, Profile, and Cross Section settings.  

    5) Copy an existing xin file that you want to use as your starting template and open the copy in InRoads.  

    6) Use Named Symbology Tools Add-in to "Import Named Symbology from CSV" into the copied xin file.  

    7) Verify that the import was successful through "Named Symbology Manager".  

    8) Delete Named Symbologies from the "Named Symbology Manager", if necessary.  

    9) Copy existing Styles from other xin files by using the Copy Preferences Add-in, if needed.  

    10) Create New Styles or Delete unnecessary Styles by using the "Style Manager".  

    a) Define Naming Convention for Style names and descriptions.  

    b) Edit New Styles to specify settings and references to Named Symbologies for Surface, Geometry, and Survey Features.

    c) Develop a spreadsheet to keep track of the Named Symbologies that are applied to each Feature Style.  

    11) Define Naming Convention for Preferences.  

    12) Copy existing Preferences from other xin files by using the Copy Preferences Add-in, if needed.  

    13) Create New Preferences by accessing applicable Command dialog box.  

    a) Apply Settings for Preference to use.  

    b) Apply Named Symbologies for Preference to use, if applicable.  

    c) Apply Styles for Preference to use, if applicable.  

    d) Select Preferences Button, and "Save As" New Preference.  

    e) Develop a spreadsheet to keep track of the Named Symbologies and/or Styles that are applied to each Command Preference.  

    14) Apply additional Command settings to New Preference by using the "Preference Manager", where appropriate.

    15) Delete Preferences from the "Preference Manager", if needed.  

    16) Maintain Control over the xin Preference file to prevent unauthorized modifications.  

    a) Allow Read-Only Access to other users.  

    17) Establish a process to address user requests for adding new Named Symbology, Styles, or Preferences to the xin file.  

    18) Repeat steps as necessary to continue building the Preference file.  


    * In order to create a CSV spreadsheet for your Named Symbology, use "Export Named Symbology to CSV" via the Named Symbology Tools Add-in to create a file, which you can then modify for your symbology settings.

    * Duplicate names of corresponding Named Symbologies, Styles, and/or Preferences, where appropriate.  I am not clear on all the benefits of duplicate naming strategies, other than you can link a Preference to a Style to facilitate dynamic display of the Preference (or something like that), if you have both a Style and Preference with the same name.  As far as linking Styles and Named Symbologies, I noticed that the file that came with the InRoads install has duplicate names for horizontal alignment points such as POB, PC, PT, POE, etc.  I am not sure if that has any significance?

    * Routinely backup your Preference file prior to making modifications to facilitate an escape plan.

    * Document changes to Named Symbologies, Styles, and Preferences via the spreadsheets you created.

    * View XML Reports to assist in keeping track of Named Symbologies and Styles, and how they applied.  See FeatureStyles.xsl, MissingNamedSymbologies.xsl, and NamedSymbologiesUse.xsl listed under the XIN folder and LevelFromCode.xsl under the Survey folder when going into View XML Reports.

    Definitions from InRoads Help:

    * "A named symbology stores a large set of parameters that define exactly how a point, line, or piece of text will appear in plan view, in profiles, and in cross sections.  The types of parameters stored in a named symbology include: color, level, line weight, line style, text height, text justification, text font, rotation angle, and so on."

    * "Part of the definition of a style is a named symbology. A style specifies a named symbology to control the appearance of the feature when it is displayed in plan view, in a profile, or in a cross section."

    My Compiled Definitions:

    * Preferences define settings for a selected command.  Settings can reference command specific settings, Styles, and/or Named Symbologies.

    * A Preferences File (xin file) contains definitions for Named Symbology, Styles, and Preferences.  Not sure but it seems that the xin file may even contain additional information?