This is usually solved by Network Graphing techniques. There are a couple of ways:

1. Building logical tables of Nodes and Links and using SQL recursion to trace through the Links table from a Start Node to an End Node.
2. Building a geometric network of Nodes and Links and building pathways

I won't go too much into Method 1, because it actually sounds like you have the geometry data already to do Method 2. Essentially, you just need to move the ends of the split lines to the same elevation as the intersecting Nodes, remove the intermediate vertices, recombine the lines by their Unique Flow Path ID. By definition, the resulting line will be an ordered list of vertices, with an ordered set of Z values/elevations

1. With the split lines, remove any Intermediate Vertices with VertexRemover. The aim is to only leave behind vertices that correspond with your Elevation Nodes, which will be the end nodes of the aplit lines. Set "Coordinate Index" = 1, and "Number to Remove" = NumCoords()-2
2. Attribute the split lines with their Start Elevation: FeatureJoiner->FromNodeID = NodeID
3. Adjust the Z coordinate of the start vertex with VertexCreator: Mode = Replace Point At Index. Index=0, Z=FromNodeElevation
4. Attribute the split lines with their End Elevation: FeatureJoiner->ToNodeID = NodeID
5. Adjust the Z coordinate of the end vertex with VertexCreator: Mode=Replace Point At Index. Index=1, Z=ToNodeElevaton
6. Join all the Split Lines back together with LineCombiner: Group By the Flow Path ID

So Step 6 basically creates an ordered array of X,Y,Z points as LineCombiner in this situation orders your network graph for you because it uses a geometric end point relationship to infer the logical order of the lines.

Getting this array out into a table is then just using CoordinateExtractor->All Points, and exploding the resulting ordered list of coordinates with ListExploder. Because in Step 1 any vertices that were not the Elevation Nodes got removed, then then the ordered coordinate list is just the Elevation Nodes.

@jacklonsdale Do you have a small sample dataset that you can share with the community to experiment with?

Hi bwn,

Thanks for the very detailed suggestion! I think it may fall down at the final hurdle however since I have multiple flows that converge down the same pathway at points which the LineCombiner doesn't deal well with!

Hi Mark. Unfortunately not, it falls under client protection i'm afraid.

Then that would mean that there is not a unique Flow Path ID as there will be segments belonging to multiple flow paths.

A variation to this (which I just used on a nearly identical project) is then to instead use ShortestPathFinder instead of LineCombiner, to derive the contiguous paths from the upstream points to the downstream point on the flow subnetwork. These paths will reuse the same common line sections to create multiple flow paths. Getting these into a single line is just taking the output of ShortestPathFinder and putting it through GeometryRefiner. Everything else is as described above.

The flow subnetworks themselves can be grouped with TopologyCalculator to limit ShortestPathFinder to only using start and end nodes on the connected flow paths. Start and End Nodes will be those that have only 1 Edge connected to then as output by TopologyBuilder.