I have read through the other post and left a comment regarding the identification of watercourse origin and mouth segments. But I took a different approach to solving this problem overall, so will post it here. I started with your method of LineCombiner paired with PathSplitter however I skipped the Orientor. I took those features and created “start” and “end” values only for the first segments of each watercourse. I then passed the features into a custom transformer that was GroupedBy the watercourse.
Within the GroupedBy custom transformer I tested the watercourse to determine if the Orientation was correct. If it was not, I ran the data through an Orientor, LineCombiner, and PathSplitter to fix the segment order. Then I utilized the Adjacent Feature functionality of the AttributeManager to reference the attributes of the previous feature to calculate the start and end values for all features.

I do not think this is a complete solution, but hopefully it helps. A better way to identify origin and mouth segments is still needed. 

Unfortunately, I do not have access to 2024, so I did this in 2022. 

​ ​

Hi @liamfez, thanks for your answer! I think both of watercourses are oriented “correctly”, i.e. they were digitalized from the origin to the mouth. If you see the image below, after the spathsplitter, the _segment_number it’s ‘0’ for the first segment digitalized in the origin.

That’s why my logic to apply an orientor before the linecombiner and pathsplitter, to have the _segment_number = 0 in the mouth segment. That’s because the calcul must start in the mouth, the segment who arrive to the mouth must have start = 0, end = lenght segment.

I don't know if I'm missing something, but for me with this logic we can define the mouth segment, it will be the _segment_number 0 right?

Also, the “idsegment” it will vary if modifications are done so it’s not stable. I should have removed it from the data sample, I’m sorry about it.

Your .fmw works fine, except for the fact that the calculation was done in reverse for the watercourse gwlnr = 0031130000. I have tried to fix your custom transformer but I am finding it a bit complex. I just tried to connect both of output from testfilter (correct and incorrect orientation port) to the Orientor transformer and it’s works.

​What do you think about it? 

Thank you for your help, I am very grateful!

Pablo

I have read through the other post and left a comment regarding the identification of watercourse origin and mouth segments. But I took a different approach to solving this problem overall, so will post it here. I started with your method of LineCombiner paired with PathSplitter however I skipped the Orientor. I took those features and created “start” and “end” values only for the first segments of each watercourse. I then passed the features into a custom transformer that was GroupedBy the watercourse.
Within the GroupedBy custom transformer I tested the watercourse to determine if the Orientation was correct. If it was not, I ran the data through an Orientor, LineCombiner, and PathSplitter to fix the segment order. Then I utilized the Adjacent Feature functionality of the AttributeManager to reference the attributes of the previous feature to calculate the start and end values for all features.

I do not think this is a complete solution, but hopefully it helps. A better way to identify origin and mouth segments is still needed. 

Unfortunately, I do not have access to 2024, so I did this in 2022. 

​ ​

Hi @liamfez, thanks for your answer! I think both of watercourses are oriented “correctly”, i.e. they were digitalized from the origin to the mouth. If you see the image below, after the spathsplitter, the _segment_number it’s ‘0’ for the first segment digitalized in the origin.

 

That’s why my logic to apply an orientor before the linecombiner and pathsplitter, to have the _segment_number = 0 in the mouth segment. That’s because the calcul must start in the mouth, the segment who arrive to the mouth must have start = 0, end = lenght segment.

I don't know if I'm missing something, but for me with this logic we can define the mouth segment, it will be the _segment_number 0 right?

Also, the “idsegment” it will vary if modifications are done so it’s not stable. I should have removed it from the data sample, I’m sorry about it.

Your .fmw works fine, except for the fact that the calculation was done in reverse for the watercourse gwlnr = 0031130000. I have tried to fix your custom transformer but I am finding it a bit complex. I just tried to connect both of output from testfilter (correct and incorrect orientation port) to the Orientor transformer and it’s works.

 

​What do you think about it? 

 

Thank you for your help, I am very grateful!

 

Pablo

Hello.

The flow I gave you at the beginning would already be the solution you were looking for if your data weren't messed up in the order of feature records.

Since you wanted to group by an attribute, all you had to do was group. I didn't even need to add any transformers.

In red the boxes you needed to place group by (gwlnr_ju)
 

So that part was already done.

From what I understand, the problem was in your flow of arranging the position in the attribute table.

Testing the flow you did, it doesn't work, this Orientor has no reason to be there, the rest of your solution I kept (although I would do it another way for myself).
 

Now IF, and only IF, your drainage is all vectored in the correct direction of the river and there are no cycles.

This solution that I am sending will automatically find the outlet of all drains and correct them all, regardless of how many there are.

So it fall back on the solution I had already sent, only with grouping this time.

I have read through the other post and left a comment regarding the identification of watercourse origin and mouth segments. But I took a different approach to solving this problem overall, so will post it here. I started with your method of LineCombiner paired with PathSplitter however I skipped the Orientor. I took those features and created “start” and “end” values only for the first segments of each watercourse. I then passed the features into a custom transformer that was GroupedBy the watercourse.
Within the GroupedBy custom transformer I tested the watercourse to determine if the Orientation was correct. If it was not, I ran the data through an Orientor, LineCombiner, and PathSplitter to fix the segment order. Then I utilized the Adjacent Feature functionality of the AttributeManager to reference the attributes of the previous feature to calculate the start and end values for all features.

I do not think this is a complete solution, but hopefully it helps. A better way to identify origin and mouth segments is still needed. 

Unfortunately, I do not have access to 2024, so I did this in 2022. 

​ ​

Hi @liamfez, thanks for your answer! I think both of watercourses are oriented “correctly”, i.e. they were digitalized from the origin to the mouth. If you see the image below, after the spathsplitter, the _segment_number it’s ‘0’ for the first segment digitalized in the origin.

 

That’s why my logic to apply an orientor before the linecombiner and pathsplitter, to have the _segment_number = 0 in the mouth segment. That’s because the calcul must start in the mouth, the segment who arrive to the mouth must have start = 0, end = lenght segment.

I don't know if I'm missing something, but for me with this logic we can define the mouth segment, it will be the _segment_number 0 right?

Also, the “idsegment” it will vary if modifications are done so it’s not stable. I should have removed it from the data sample, I’m sorry about it.

Your .fmw works fine, except for the fact that the calculation was done in reverse for the watercourse gwlnr = 0031130000. I have tried to fix your custom transformer but I am finding it a bit complex. I just tried to connect both of output from testfilter (correct and incorrect orientation port) to the Orientor transformer and it’s works.

 

​What do you think about it? 

 

Thank you for your help, I am very grateful!

 

Pablo

If the watercourses are already oriented correctly in my initial workspace, then almost all of the custom transformer can be removed. I have made this change and re-zipped it. 

@pabloolivaresm , with the proper grouping it sounds like @chosbacon’s solution is also working. For either solution, the important part is making sure the lines “flow” in the correct direction.

I liked your solution, the move you made with the attribute manager is clean and elegant.

Thanks. I really liked you solution to cleaning up/preparing the watercourse data. I think the data prep, ensuring segments and watercourses are oriented and identified properly is going to be important for taking the solutions and applying them to the full dataset. 

@chosbacon @liamfez Thanks a lot both of you! I tryed both solutions and works fine. I must say that the calculation must be made in reverse of the direction of orientation of the watercourse, starting from the end, to put it in a simple way, that is why the need for the Orientor. Your models are correct but they calculate the first segment at the origin, not at the mouth. I think I am not clear enough to explain, sorry for that! It’s hard to chose the best answer when both of them are the best, but as in the first post I choosed @chosbacon, this time I’ll choose @liamfez. Thanks a lot!