calculating lenght start and end in line segments

Calculate the length of each segment

Make a Loop, starting from the first segment and always adding a new segment at the end of the loop; 

To do this, use a group and sample process (always the first element);

Calculate (lenght) as statistc Calculator in SUM mode; 

at the end, each group (which must be group + 1 for each round), will be the end value, to have the start value just reduce the start value from the end value

chosbacon wrote:

 

Exemple on FME(R) 2023.1.0.0 (20230825 - Build 23619 - WIN64)

Hi @chosbacon , thanks for answer! Im trying to replicate your model. The counter is not working as expected, I think bcause the order of segments it’s not linear. I attached a sample with a segments of a waterscourse.

pabloolivaresm wrote:

chosbacon wrote:

Calculate the length of each segment

Make a Loop, starting from the first segment and always adding a new segment at the end of the loop; 

To do this, use a group and sample process (always the first element);

Calculate (lenght) as statistc Calculator in SUM mode; 

at the end, each group (which must be group + 1 for each round), will be the end value, to have the start value just reduce the start value from the end value

chosbacon wrote:

 

Exemple on FME(R) 2023.1.0.0 (20230825 - Build 23619 - WIN64)

 

Hi @chosbacon , thanks for answer! Im trying to replicate your model. The counter is not working as expected, I think bcause the order of segments it’s not linear. I attached a sample with a segments of a waterscourse.

 

I found a way with line combiner and pathsplitter

@chosbacon I couldn't finish the loop. When I try with just one watercourse it’s ok, but with 2 or more it’s not working,I dont know how to apply it when I have many watercourse. All segments that are part of a watercourse share an identifier (gwlnr). I attached a sample with the model in FME and a geopackage file

Well, this is much more difficult than the case you asked for, because when the river starts to have arms there is a problem with the construction of the idea. How do you intend to accumulate after the confluence? Because it will have two different values

@chosbacon Yes, your right, it was not clear. my bad.

The idea it’s to calculate the watercourse individually, that’s means the calculation does not take into account the segments of other watercourses.

In the image here above, the purple’s segments all have a common ID (gwlr in the sample exemple), the same for blue’s segments. 

thanks again for your support

Pablo

@pabloolivaresm  When initially testing with your sample data, it appeared that one of the watercourses was oriented correctly, but the other was not. Using the Orientor before the LineCombiner seemed to flip the issue (one watercourse had its first segment as the origin, the other the mouth).

For your sample specifically I was able to flip just one but that was because the true start segment happened to have a lower original “idsegment” than the true end segment. My temporary solution was to test each of the two watercourses min and max values looking at both the original “idsegment” and the created “_segment_number” values to determine which needed to be run through the Orientor.

While it worked for your sample it is not a robust solution, do you have any methods for identifying which segment is the mouth and which the origin?

pabloolivaresm wrote:

@chosbacon Yes, your right, it was not clear. my bad.

 

The idea it’s to calculate the watercourse individually, that’s means the calculation does not take into account the segments of other watercourses.

In the image here above, the purple’s segments all have a common ID (gwlr in the sample exemple), the same for blue’s segments. 

 

thanks again for your support

 

Pablo

 

Is it just going to be a basin? Or will it have more than one river basin? Because a single drainage network or several networks vary in the solution. Furthermore, your data seems a bit messy, do you have a point that identifies the river outlet or the river source?

If yes, which one?
It will help to tidy up the data.

Hi @liamfez, thanks for your answer! I answer you in the other post but I put here anyway. 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, because the calcul must start in the mouth, the segment who arrive to the mouth must have start = 0, end = lenght segment. The “idsegment” it will vary if modifications are done so it’s not stable

chosbacon wrote:

pabloolivaresm wrote:

@chosbacon Yes, your right, it was not clear. my bad.

 

The idea it’s to calculate the watercourse individually, that’s means the calculation does not take into account the segments of other watercourses.

In the image here above, the purple’s segments all have a common ID (gwlr in the sample exemple), the same for blue’s segments. 

 

thanks again for your support

 

Pablo

 

 

Is it just going to be a basin? Or will it have more than one river basin? Because a single drainage network or several networks vary in the solution. Furthermore, your data seems a bit messy, do you have a point that identifies the river outlet or the river source?

 

If yes, which one?
It will help to tidy up the data.

Hi again @chosbacon, it will be a hydrographic network, with many watercourse, some of them with many segments and other with just one segment. About the point to identify river outlet and source I don’t really have a point to identify them. As I say to @liamfez, maybe there it’s something that I’m missing, but for me with the LineCombiner and PathSplitter I can get _segment_number in order, and if before I put a Orientor, I have _segment_order = 0 to the river outlet.

Thanks for your support, I am very grateful!

Pablo

pabloolivaresm wrote:

liamfez wrote:

@pabloolivaresm  When initially testing with your sample data, it appeared that one of the watercourses was oriented correctly, but the other was not. Using the Orientor before the LineCombiner seemed to flip the issue (one watercourse had its first segment as the origin, the other the mouth).

For your sample specifically I was able to flip just one but that was because the true start segment happened to have a lower original “idsegment” than the true end segment. My temporary solution was to test each of the two watercourses min and max values looking at both the original “idsegment” and the created “_segment_number” values to determine which needed to be run through the Orientor.

While it worked for your sample it is not a robust solution, do you have any methods for identifying which segment is the mouth and which the origin?

 

Hi @liamfez, thanks for your answer! I answer you in the other post but I put here anyway. 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, because the calcul must start in the mouth, the segment who arrive to the mouth must have start = 0, end = lenght segment. The “idsegment” it will vary if modifications are done so it’s not stable

 

 

chosbacon wrote:

pabloolivaresm wrote:

@chosbacon Yes, your right, it was not clear. my bad.

 

The idea it’s to calculate the watercourse individually, that’s means the calculation does not take into account the segments of other watercourses.

In the image here above, the purple’s segments all have a common ID (gwlr in the sample exemple), the same for blue’s segments. 

 

thanks again for your support

 

Pablo

 

 

Is it just going to be a basin? Or will it have more than one river basin? Because a single drainage network or several networks vary in the solution. Furthermore, your data seems a bit messy, do you have a point that identifies the river outlet or the river source?

 

If yes, which one?
It will help to tidy up the data.

 

Hi again @chosbacon, it will be a hydrographic network, with many watercourse, some of them with many segments and other with just one segment. About the point to identify river outlet and source I don’t really have a point to identify them. As I say to @liamfez, maybe there it’s something that I’m missing, but for me with the LineCombiner and PathSplitter I can get _segment_number in order, and if before I put a Orientor, I have _segment_order = 0 to the river outlet.

 

Thanks for your support, I am very grateful!

 

Pablo

 

 

I saw you opened a second topic, I'll respond in the other one