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.
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.