I have a number of threads on this topic asking very specific questions - sadly most of these have few responses and many of those that do, are ones that I myself have answered. So, I am trying a different approach. I am launching this as a discussion where I am hoping others will share their thoughts on Feature Definitions as we move forward into a world of Open Roads without native applications. For this discussion. we can assume that at some point, all Native Styles will get Element Templates to drive their symbologies and some internal Open Roads tool to control the context of these displays, formerly controlled by the Native Styles and Applications.
At some point in the not too distant future, all of us InRoads, GEOPAK and MX users will find ourselves in a world where our tools and files are 100% identical in data content and more. We will be freed from the thoughts of "Well in ____, we used to do this with that..." and really need to have a common understanding of what type of real world items items need to be represented by what type of Feature Definition. But more importantly, how should those Feature Definitions be configured.
Some of these are pretty inflexible.
A Surface Feature Definition seems to have one of two uses and these have a pretty fixed configuration. In Cross Sections, their symbology comes from their 3D display setting, which come from an Element Template- General Settings.
- Components - Open and Closed shapes in Templates that create meshes in the 3D model when used with Corridors and Linear Templates. No other settings seem to apply.
- Terrain Elements - Newly added MicroStation elements that use an Extended Element Template to control their display in a 3D model or when referenced into another file. These also can use a Profile symbology to display their surface in a Profile View (and eventually Profile Plot)
A Point Feature Definition appears to be a direct representation of a COGO Point or a Surface Point Feature. At least, these seem to be the only things that create Point Feature Definitions during the Link to Native process. (During the secondary linking process for Survey Feature Definitions on the InRoads Side, all Survey Features convert as Linear Feature Definitions.)
- Random Surface Points - In InRoads, it was possible to assign many different Feature Styles to different groups of Random Points, These styles were preserved within the DTM due to the Feature Based DTM. In Open Roads, to replicate the same thing, you would need to have linked points in the 3D file that are in a surface due to the link and if moved or deleted in their DGN, would be moved or deleted in the Terrain Element. These difference between InRoads and Open Roads need to be evaluated and it should be decided if maintaining this link is a best practice or if having source points stored in a DTM is all that is needed moving forward.
- COGO Points - These will most likely continue is a manner similar to past uses.
Both of these uses for Point Feature Definitions should be analysed to determine a display practice. In InRoads 2D and 3D displays were created from the same symbology. There was no easy way to have two different displays for 2D or 3D models. Open Roads removes this limitation. For some items, a different display should be considered for rendering purposes. A 2D point could use a print ready cell for contract documents while the 3D cell could be a 3D representation of the actual object being represented. Trees, fire Hydrants, light/utility/signal poles, etc. are all candidates for this type of dual representation. This also points out an issue with Survey Feature Definitions. To get a similar dual display, it will be necessary to convert survey points to COGO or non-survey points. Any methods that exist in Open Roads to accomplish this need to be evaluated.
The last type of Feature Definition to discuss is Linear. During the Link to Native Step, any and all features that generate a Linear Definition get "merged" under a common Linear Feature Definition name. When the secondary Link for Survey Feature Definitions is performed, any Survey Feature that is the same name as an already created Linear Feature Definition gets renamed with a sequence number. This adds a complexity to the process, especially if the original intent in the native files were that certain features representing the same item but as Surface, COGO or Survey were supposed to share a style name and symbology. To restore this process requires substantial editing of the Feature Definitions following the linking processes. For now, lets put that aside.
A Linear Feature Definition represents some type of linear element in the real world. Some are below grade, aligned coincidentally in the X & Y with an at grade feature. Some have traditionally only been drawn a 2D representations. Most, under the native products could only display in 2D or 3D using a single display configuration. And like Point Feature Definitions, Open Roads now allows a dual display mode - one for 2D and another for 3D. Unlike points however, many of these 3D representations do not represent so much as an object as they represent the edge of an object or a change of grade between the two surface areas on opposite sides of the linear feature.
Thus the question is, which type of objects being represented by the 3D linear portion of a feature should have a different display configuration than the 2D linear portion of a feature. A Pipe or a Traffic Barrier come to mind as yes, we need two display settings. The edges of pavement, shoulders, curb breaklines are not so cut and dry. A 2D display driven by traditional construction plan presentation is a hard and fast requirement. How many of these are displayed in 3D - not so much.
An argument can be made that only the component meshes need be displayed in the 3D model, but unlike a terrain element, corridor created graphics from a reference file can only be modified by level based display manipulation. So when working in a group, it might be a best practice to always close a file containing corridors with Meshes and Features displayed so others can turn off and on those items as needed using level display tools. This still doesn't answer the question of does 2D need to be different than 3D display. But it does point out that component meshes and 3D feature displays should be on different levels.
Please take the time to read this and offer any comments, suggestions, corrections or clarifications that you feel need to be made. As stated early on in this post, we are not too far from the days of an Open Roads product that does not use any Native Styles or tools. When that day comes, you may find your old workflows and settings are obsolete and the more input we get on this topic, the better we will all be able to move forward when the time comes to take that plunge.