The changes to how linear targets are defined in SS3 were done for various reasons. First, All linear targeting (H/V/Both) can only be accomplished by using Target Aliasing. We found during extensive internal workflow testing that trying to pick specific element names, when defining linear targets, simply did not work. First, the targets needed had to exist in the dgn or a referenced dgn. Second, since any “civilized” element, named or unnamed, 2D or 3d, with or without a profile, can be a target, the list can be very large to display in a combo box drop down. We found that a better approach was to allow the user to enter any string to represent the target. This was set up to be similar to the parametric constraint labels where any target entered will then be in the list so the user can simply select an existing target. So the targets in this case could be “Left Ditch” and “Right Ditch”. This template can then easily be reused in other projects. When the corridor is created, the user simply selects the linear elements that represent the left and right ditches in the Target Alias dialog box. I know this is not as efficient from a user’s standpoint as simply targeting Feature Definitions (Styles in SS2), but is much more efficient from a processing standpoint because the code does not have to scan the file for all elements with the matching Feature Definition. Which brings me to the next point. In SS2, when a style was targeted, we would scan all of the alignment elements and the dtm features for elements that had a matching style, then attempt to intersect each one at each station and use the closest intersection as the solution. In SS3, because everything now resides in dgn files, we need to scan the entire dgn file and all attached reference files looking for elements with the targeted feature definition. This process was very inefficient, particularly for large files, and/or many reference files, so we instituted the Corridor References list. Now any elements that are to be targeted via a Feature Definition target need to be added the corridor’s reference list. This means there is no longer a way to make Feature Definition targets simply “work”. In conclusion, in SS3, a user must add linear elements that are going to be targeted to a list - either the target alias list, or the corridor reference list, and I will reiterate what I have said here and have said in various presentations – targeting specific elements is always more efficient then targeting something via a Feature Definition, because there is no need to scan the file(s).
Of course, just because I’ve described our reasoning for these changes, it doesn’t necessarily make this the best solution. We are always open to suggestions on how to make our products better, so we will always research any suggestions sent to us.
I am deliberately not addressing the multiple vertical feature definition issue because I am not knowledgeable as to how/why it was architected that way, but somebody else from Bentley should be able to answer this.
Regards,
Denis