Convert line elevations to horizontal only

Hi

Is there a way to explode / convert a linestring to only contain elevations along the horizontal geometry? A project I am working on involves a lot of Contours at elevation and similar commands which insert a single vertical elevation on the lines geometry. The problem is that if you join this line to another line it merges the geometry and the line often ends up following a grade from the joined line.

Hey Bruce
Take a look at the “Absolute” option of the “Change Elevation” command. Unless I’m misunderstanding what you’re looking for, this may do the trick. This is the method I use in the situation I think you’re describing.

HI Richard

Thanks for the response but that’s not quite what I’m after. Its a bit tricky to describe but if you explode a contour that’s been formed by ‘Contour at elevation’ and then edit it, you will notice that all the horizontal geometry nodes have an elevation of ‘?’ and there will be a singular vertical geometry elevation placed at the start of the line. This works if you don’t join it with any other line. If you do it will adopt the grade of the joined line which causes problems. I tried the absolute command you mentioned but it doesn’t seem to change anything.

I just found the solution - Adjust LS elevation macro does the trick

2 Likes

Yea I just fully realized your situation after your second post. I’ve either set a VPI at the far end of the line to “lock it down” before joining or use the Adjust LS macro as you’ve mentioned when I’ve encounter (and been burnt by) the same situation.

2 Likes

This is always a difficult discussion around what to do in these situations. i dont think it is really a matter of defining the VPI in the horizontal control or the Vertical Control it is more a matter of what you want to happen when you join lines that contain different elevations, and also how you are letting linestrings extend vertical or not before you join lines

Take two lines that are separated laterally. One line has elevation of 100 defined at one end (the far end away from the join) and the other line is elevation 110 at the point closest to where the two lines would be joined.

The options are

Join Line 1 to Line 2 - add a VPI at the end of line 1 = to the elevation of the line ie 100 so it locks down the elevation of line 1 to be 100 over its entire length and do the same for line 2 at elevation 110 - this will then give a line that has elevations 100, 100, 110, 110 with a slope between the two lines that follows the gap between the two lines

Join line 1 to line 2 - do not add VPIs at the end of the lines - you will now get elevations 100, undefined, 110, undefined and you will get a slope that starts at node 1 that goes all the way to node 4 if you have extend vertical enabled and that stops at node 3 if you do not have extend vertical enabled

This is the simple case

Now take two 3 point lines

Line 1 has elevation 100, 101, 102 and line 2 has elevations 105, undefned, undefined

Join the 2 together and you get 100, 101, 102, 105, undefined, undefined - again depending on how you have extend vertical set points 5 and 6 will either be undefined or set on a slope that extends between points 3 and 4.

Bottom line - there are so many options here - if you have contours they typically start out life as polylines with a constant elevation. we may convert them to linestrings so now they are linestrings with a single elevation at the start point). You could argue that we should add a VPI on the Start and End point of a constant height line so that this issue doesn’t happen. I am sure that there are some downsides to that somewhere. I don’t have any magical way today to automate this with current TMLs - but of course a tool that joins lines together could be “taught” rules on how to handle elevation on joined lines - ie in this case if you wanted a slope between Line 1 and Line 2 but only between points 2 and 3 and you wanted line 1 and line 2 ie points 1 & 2 and 3 & 4 to hold the elevations of the original lines that could of course be done - but please provide the list of elevation option that you want for 3D single elevation lines and 3D multi elevation lines and lines where the start and end points don’t have VPIs etc. and all combinations of how you want those handled - because I don’t think that is a simple or easy list to create - In this case you dont feel TBC is doing the right thing - but in other situations it may well be doing the right thing - it all depends on the data and the situation.

You are however right to say that putting a slope from Start to end when you start out with two level lines (constant elevation) does not appear to be the correct answer and I have seen similar things personally.

Alan

If you have a lot of lines that need a second VPI at the “unelevated end” you can draw a 3D line between the ends that are not elevated and then use the Elevate Lines by Intersecting lines command to elevate them in less steps than editing each one individually - then delete the unneeded line and then you will be better off when you join the lines together.

Alan

This is always a difficult discussion around what to do in these situations. i dont think it is really a matter of defining the VPI in the horizontal control or the Vertical Control it is more a matter of what you want to happen when you join lines that contain different elevations, and also how you are letting linestrings extend vertical or not before you join lines

Take two lines that are separated laterally. One line has elevation of 100 defined at one end (the far end away from the join) and the other line is elevation 110 at the point closest to where the two lines would be joined.

The options are

Join Line 1 to Line 2 - add a VPI at the end of line 1 = to the elevation of the line ie 100 so it locks down the elevation of line 1 to be 100 over its entire length and do the same for line 2 at elevation 110 - this will then give a line that has elevations 100, 100, 110, 110 with a slope between the two lines that follows the gap between the two lines

Join line 1 to line 2 - do not add VPIs at the end of the lines - you will now get elevations 100, undefined, 110, undefined and you will get a slope that starts at node 1 that goes all the way to node 4 if you have extend vertical enabled and that stops at node 3 if you do not have extend vertical enabled

This is the simple case

Now take two 3 point lines

Line 1 has elevation 100, 101, 102 and line 2 has elevations 105, undefned, undefined

Join the 2 together and you get 100, 101, 102, 105, undefined, undefined - again depending on how you have extend vertical set points 5 and 6 will either be undefined or set on a slope that extends between points 3 and 4.

Bottom line - there are so many options here - if you have contours they typically start out life as polylines with a constant elevation. we may convert them to linestrings so now they are linestrings with a single elevation at the start point. You could argue that we should add a VPI on the Start and End point of a constant height line so that this issue doesn’t happen. I am sure that there are some downsides to that somewhere.

Hi Alan

Thanks for the response. It is a tricky one but I was just looking if something did exist as I had a situation where I joined lines and didn’t realise that the second line had been changed to the first lines elevation which was a bit dangerous as it was being pushed out to a machine file. Luckily I spotted it before they had worked in the area.

Agree that this can catch you out - when you join lines that have different elevations and different points on the lines that have elevation points - it is not at all clear what you should do and how the elevations should work after the Join- we are working on a new Join function and I will spend some time on the vertical part of that to see what we can do - sometimes you do want a slope to happen sometimes not - if we add VPIs automatically to constrain the existing pre Join lines then that will introduce steps in a line as a result - maybe it is a checkbox that says lock ends of source lines vertically or not - if the lines do not have vpis at the ends we add them based on the current line elevation at those points (that depends on the extend vertical on line setting being on or off) and see if that solves this. We could also say allow for extend vertical or not and if not switch off the e2xxtend vertical so that the line end is locked at the prior nodes elevation or something ,

What do you think?

Alan