Skip to main content
  • EN

So, I have a linear dataset of rivers. I have developed a RIVER_ID that serves as a unique ID per river. Saying this, one RIVER_ID usually has more than 1 unique ID depending on how long the river is. I firstly created them grouping by name in the network topology and using the Network_ID as a RIVER_ID. Later, I calculated Strahler order and used that to assign to unnamed rivers. So, what I want to locate are rivers (same RIVER_ID, could be multiple unique features) that touch a different RIVER_ID minimum two times (think about river sleeves). So, I went with Spatial Relator but I am now realising that a Spatial Relator will only give me 1 related candidates if my Requestor is touching the same IDd river at two locations and not two as I was hoping to get. Another thing that pops on my mind is using a snipper to get the first and last vertices of my Requestor feature and find a number of overlaps with other features and generate a list with these overlaps and check if there are two same RIVER_IDs. However, what is blocking me there is the fact that I don't know how to avoid to check my Requestors against the Suppliers (which are the same). So, I can do this in the SpatialRelator where I put "Attributes to differ": RIVER_ID and in that way he is for every RIVER_ID only checking features that are not of that RIVER_ID but I don't know how to do this in for example LineOnArea -- in relation to this, I use two snippers (vertex 0 and -1) and a small buffer of 0.01 and send that to LineOnArea with original lines and generate lists with RIVER_IDs. After that, I would use the FeatureCounter where I would group by my Requestor RIVER_ID and get the count of overlapping features after which I would use a sorter and matcher or something like that but the issue is that I don't know how to avoid to check the same RIVER_IDs in the LineOnArea.

 

In the photo I have selected something that I would like to locate. So, these two have different RIVER_IDs even though they are the same river because the selected one is unnamed. This is an oversimplified case because sometimes these are quite longer and have rivers of their own flowing into them.

Hello @matija​ , do you have some sample data so I can try a couple of things for you?

Hello @deanhowell​ I can't share the data but I can draw a small subset so I'll send that later on.

If you look at the relationships{}.de9im produced by the spatial relator you should be able to identify rivers that touch at two points v rivers that only touch at one point

If you look at the relationships{}.de9im produced by the spatial relator you should be able to identify rivers that touch at two points v rivers that only touch at one point

Thanks @ebygomm​ But how would I differ a river that has two tributaries from a river that is a river sleeve and intersects/touches the same river at two locations. This is what I am having issues with. I have firstly removed all the valence = 1 from my Requestors (to Spatial Relator). After that I am taking two cases:

  • One case is where related_candidates == 3 which will be a one feature (river sleeve) like the one in the picture above. Related candidates == 3 because lines are nicely combined so there is a unique feature after every valence == 3.
  • Another case is where I have a longer sleeve that is made of multiple features and has its own tributaries but it has a unique RIVER_ID. So, in the list of rivers that intersect/touch my Requestor RIVER_ID, I need to find if one of the SUPPLIER_RIVER_IDs shows 2 times and is at the start and end of my aggregated RIVER_ID. I maybe don't have to check end and start point because if it intersects at two locations with the same RIVER_ID, that should be it. I can't use the snipper because it deaggregates the feature and gives me a lot of data and I think there is a better approach.

Maybe you could explain if and how I can use the de9im to identify this cases.

Hope this helps,

Assign count ID to line (assumes line are snapped together and cleaned, if not use anchorsnapper or adjust PointOnLine's point tolerance); assign UUID and remove 1st and last vertex; route vertex to PointOnLineOverlayer transformer's Point input and count ID to Line input (generate list on output 'point', count ID); route point output to ListExploder (prefix list attribute); route to tester filtering out original features; route to statistic calculator ((group by, uuid, prefix count ID),prefix count ID, total count) and finally, features that have value of 2 or greater in attribute countid.total_count are those river ~sleeves~.Screenshot 2020-12-01 125939 

Hope this helps,

Assign count ID to line (assumes line are snapped together and cleaned, if not use anchorsnapper or adjust PointOnLine's point tolerance); assign UUID and remove 1st and last vertex; route vertex to PointOnLineOverlayer transformer's Point input and count ID to Line input (generate list on output 'point', count ID); route point output to ListExploder (prefix list attribute); route to tester filtering out original features; route to statistic calculator ((group by, uuid, prefix count ID),prefix count ID, total count) and finally, features that have value of 2 or greater in attribute countid.total_count are those river ~sleeves~.Screenshot 2020-12-01 125939 

Hi @alexlynch3450​ I get pretty much all lines with this approach but it does sound like a good idea using the VertexRemover to keep only starting and ending points. I'll try to make some use of it. On the other hand, I used a SpatialRelator to create a list of SUPPLIER_RIVER_IDs (one RIVER ID has multiple features or differing unique IDs) and used a histogram to count the number of occurrences of the SUPPLIER_RIVER_ID (prefixed the supplier RIVER_ID with SUPPLIER), taking RIVER_IDs that have a minimum count of 3 same SUPPLIER_RIVER_IDs and there are still some issues but it seems it might produce good results. I was not aware of the VertexRemover transformer so I'll be sure to check that thoroughly. Thanks.

 

I believe that maybe by using an additional parameter in the list such as a Supplier_RIVER_ID I might be able to get the river sleeves but I'll check that tomorrow as it is late now.

@matija​ I think @ebygomm​ is on the right track with the SpatialRelator. Instead of looking at the de9im, we can count the number of different ID's that connect to a possible sleeve - ListHistogrammer. I think the criterion for a sleeve (or oxbow) is that it must touch the same line 3 times - green arrow.

imageSo we can test for lines that have three (possibly more) relationships and three of those have the same ID. If other segments can join at a sleeve junction, then you probably need to write some python to test the relations histogram. Note: This breaks down if the sleeve can also have a branch.

 

All this assumes your river network is correctly noded (i.e. all lines at a junction are split and there are no 'complex' edges).

 

I've attached a test workspace (FME 2020.2)

Hi @alexlynch3450​ I get pretty much all lines with this approach but it does sound like a good idea using the VertexRemover to keep only starting and ending points. I'll try to make some use of it. On the other hand, I used a SpatialRelator to create a list of SUPPLIER_RIVER_IDs (one RIVER ID has multiple features or differing unique IDs) and used a histogram to count the number of occurrences of the SUPPLIER_RIVER_ID (prefixed the supplier RIVER_ID with SUPPLIER), taking RIVER_IDs that have a minimum count of 3 same SUPPLIER_RIVER_IDs and there are still some issues but it seems it might produce good results. I was not aware of the VertexRemover transformer so I'll be sure to check that thoroughly. Thanks.

 

I believe that maybe by using an additional parameter in the list such as a Supplier_RIVER_ID I might be able to get the river sleeves but I'll check that tomorrow as it is late now.

Gotcha. Well this approach works with what vector information you gave. I attached the workspace for you to test.

@matija​ wondering if any of the suggestions posted here help you solve your network question on identifying river sleeves.

Reply


Community Stats

30,185
Posts
114,572
Replies
37,848
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.