I have a layer of hydrographic network lines. A watercourse is composed of one or more segments, which share an ID. I have two attributes, abscissa_start and abcissa_end, which correspond to the length of the segment in a sequence. For example, in the attached image, I have a watercourse, where the first segment measures 50m, so start_abscissa is 0, and end_abscissa is 50, the second segment measures 80m, so start_abscissa must be 50, and end_abscissa must be 130, and so on. I need to find a way to be able to calculate the two fields abcissa_start and abcissa_end in FME automatically.
The segments are always digitised from the origin to the mouth, and the calculation must be done taking into account as the first segment the one at the mouth. They already have a lenght field.
Thanks,
Page 1 / 1
Hi,
I have a layer of hydrographic network lines. A watercourse is composed of one or more segments, which share an ID. I have two attributes, abscissa_start and abcissa_end, which correspond to the length of the segment in a sequence. For example, in the attached image, I have a watercourse, where the first segment measures 50m, so start_abscissa is 0, and end_abscissa is 50, the second segment measures 80m, so start_abscissa must be 50, and end_abscissa must be 130, and so on. I need to find a way to be able to calculate the two fields abcissa_start and abcissa_end in FME automatically.
The segments are always digitised from the origin to the mouth, and the calculation must be done taking into account as the first segment the one at the mouth. They already have a lenght field.
Thanks,
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
Exemple on FME(R) 2023.1.0.0 (20230825 - Build 23619 - WIN64)
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
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.
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
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
@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?
@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.
@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 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 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 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
