It appears the latest version of BC-HCE defaults to a zero elevation for the node when snapping to the intersection of any lines regardless of their elevations. This works differently than in the past? It may occur on other Snap commands too but I haven't tested them much.....
Would it be possible to consistently populate the elevation from the first (or last) selected element or default to the elevation entry box? I thought this was how it worked in the past....
Also, it would be helpful to default the elevation to undefined if the elevation of the first selected line is undefined.
Glenn
I just tried this in the 4.12 Patch that is being prepared for release.
If I create 2 Linestrings with undefined elevation as shown below
and then turn on Intersection snap and draw from a location with undefined elevation to the intersection of the two lines (which has no elevation) I get the coordinate and the Elevation field is left blank and it is created as Undefined when I click OK to Accept that location.
If I use the same two linestrings and elevate them both to an elevation of 100' and then draw a new linestring from a location with undefined elevation to the intersection of the two lines (which would now be at 100') then the second node created has an elevation of 100'
If I use the same two linestrings and change one of the elevations to 105' so that at the interersection the elevation could be 100, 105 or the mid point of 102.5 the software takes 105 as the elevation
It always seems to take the Highest Value of the Intersection - I tried changing each line in turn and it always picked the highest elevation at the crossing location.
I also tested with the following condition
In this case I would say that we are inconsistent with the earlier adopted practice and that we did not take the higher location in this case but the lower condition (this to me is inconsistent behavior - I would agree)
In this case it has extracted an elevation from the elevated line (which is the best it can do and I think is correct behavior)
In this example I turned off the Extend Vertical Property of the linestring so it has no elevation at the Intersection point so again the intersection elevation is computed from the lower string. When there is only one VPI of 105 elevation, it auto applies 105 to the whole line until you add a 2nd VPI (again I would say this is the correct behavior).
I also tested this with the Intersection Snap (selected from Right Click) and in this case it always sets the elevation to 0.00 which I think is what you are saying in your initial comment / question. I would say that having read your question and having tested this (to a point), that we should do something to the Running Snaps and to the Snaps Selected using Right Click that better controls the Elevations based on what the source data selected for the snap has available - and to define rules that are applied to the snaps (and if possible give the option to control how Z is determined in the case of ambiguity (High, Low, Mean, Undefined, 0 or other (User Entered)) and whether we want to add VPI to the source lines also at the same Z as that selected / computed/ entered.
I would say that the following behavior would be better
1) If Undefined elevations for both lines then the intersection would be Undefined elevation - should be able to override with a value and OK to accept or just accept the undefined value (question here is do you want to always have to tap Save to accept the value (you would have to do that if you want the software to pause and give options)
2) If the same elevation on both lines at the intersection then default to the same elevation for the Intersection and give the option to override or accept
3) If Different Elevations at the Intersection then Take the Highest Value but allow selection of Lowest or Mean Elevation at intersection point (in this case I would say that you may also want to add that same Mean Elevation or Highest or Lowest Elevation selected to the other two lines at that point so that they all agree at the intersection point after the change (that way you don't have to fix all the lines afterwards to match).
For me - where the Elevation could be one of None, the same as, The High, The Low or the Mean elevation we should have a Pop Up box (or accessible Snap Settings) that give you the options with the defaults and the option to Check a box that adds a VPI to the source lines of the intersection (or any other snap as appropriate) so you can select and OK to take the action - you could also have a Check Box for "Do Not Ask This question again and it would use your default behavior request (e.g. Mean Elevation from there on (in that execution of the command).
I agree that this should be consistent (and it seems like in at least 4.12 it is partially consistent for Running Snaps but not selected snaps), but I too would like these options while editing data - this also applies to when you are fixing Flags - in that instance where you have crossing breaklines at different elevations you get the Flag - in this case it always uses the lowest line elevation and flags the higher one (unless there are 3 lines that intersect and 2/3 have the higher elevation in which case it uses the higher Elevation and flags the lower one. Fixing these always involves adding a VPI at the Crossing and setting the two lines to the same height at the crossing location and in that case it is typically the Highest, the Lowest, The Mean or some defined value as the fix - doing this in one quick edit as opposed to several separate edits would be a huge productivity saving in my eyes - would you agree?
I tested the Perpendicular snap to a line with Z = 105 and it leaves the Elevation field blank and you can click on the line with elevation of 105 to create the Z. Again the same logic should apply to this and all other Snaps - I have put in a request to review this and address to enhance 3D Editing using Running or Selected Snaps.
Thanks for raising this question
Alan