Skip to main content
Solved

Merging Multipart Polylines to create elevation profiles in FME

  • March 31, 2022
  • 3 replies
  • 98 views

Forum|alt.badge.img

I have about 2000 line segments that need to be aggregated based on a specific field. First I sort them based on the order they are supposed to be merged in, then I aggregate them if there's more than 1 segment. This results in about 1100 multipart polylines (not all of them are multipart, and some are just made of 1 segment, but others can be made of up to 12 segments).

 

This works really well for my output data, and the lines are all merged correctly. However, at a closer look, my elevation profiles don't make sense. It appears that even though the segments are in the correct order, some of the segments have a different orientation of their neighboring segment, i.e. one is going North to South, and the next is going South to North. Hopefully the attached diagram can help illustrate this.

 

Line Segments Issue for Elevation Profile 

I've tried many different transformers to try and fix this without updating the underlying dataset, but I'm not sure if there's a way to fix this in FME? Is my only option to fix the underlying dataset (the 2000 segments) or identify the ones that should be reversed before going into the aggregator?

 

Currently there is no attribute in the data to say which direction the line is "supposed" to be oriented. I just want the coordinates to be continuous for the elevation profile. Any ideas?Example Elevation Profile

Best answer by nielsgerrits

If your requirement is to make continuous lines, you can use a LineCombiner to do this. It will fix the orientation.

 

If you must have aggregates, you can expose the coordinate of the first and last point of each line and compare these to the previous feature to determine if the orientation is switched using an AttributeCreator with Adjacent Features and conditional values. When a line is switched, you can reverse the orientation using the Orientor. Attached a sample workspace demonstrating this.

2022-03-31_05h45_02Adjacent Features can be tricky to get right, my best practice is to copy the data to Excel first, build the formula there and then recreate the formula in FME using conditional values.

This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

3 replies

nielsgerrits
VIP
Forum|alt.badge.img+60
  • 2938 replies
  • Best Answer
  • March 31, 2022

If your requirement is to make continuous lines, you can use a LineCombiner to do this. It will fix the orientation.

 

If you must have aggregates, you can expose the coordinate of the first and last point of each line and compare these to the previous feature to determine if the orientation is switched using an AttributeCreator with Adjacent Features and conditional values. When a line is switched, you can reverse the orientation using the Orientor. Attached a sample workspace demonstrating this.

2022-03-31_05h45_02Adjacent Features can be tricky to get right, my best practice is to copy the data to Excel first, build the formula there and then recreate the formula in FME using conditional values.


Forum|alt.badge.img
  • Author
  • 6 replies
  • April 6, 2022

@nielsgerrits​ Thanks for your advice.

 

The LineCombiner is a good solution for most of the lines, as long as the data is sorted and grouped properly before going in.

 

As for the adjacent feature workflow, this would have worked well, but the underlying data is so inconsistent and needs to be fixed anyway. The problem I had with some of my data was that the first segment was going in the wrong direction, which means the subsequent segments don't end up going in the correct direction either.

 

Interesting workflow though that might end up getting used in the future, so thanks for sharing!


nielsgerrits
VIP
Forum|alt.badge.img+60
  • 2938 replies
  • April 6, 2022

@nielsgerrits​ Thanks for your advice.

 

The LineCombiner is a good solution for most of the lines, as long as the data is sorted and grouped properly before going in.

 

As for the adjacent feature workflow, this would have worked well, but the underlying data is so inconsistent and needs to be fixed anyway. The problem I had with some of my data was that the first segment was going in the wrong direction, which means the subsequent segments don't end up going in the correct direction either.

 

Interesting workflow though that might end up getting used in the future, so thanks for sharing!

One thing to add, I do not think that the LineCombiner requires the features to be sorted to work correctly. It just connects lines on endpoints if you set Input Feature Topology to End noded. Yes the geometry needs to be correct, but you can use a Snapper upstream of the LineCombiner to fix this.