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
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.
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.
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 civil.xin 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?