Hello everyone,
I’m searching for a method that allows me to retrieve the drainage basins from a mesh.
In this simple example I recreate a mesh with two basins and I want to obtain two separate meshes, i searched for a topic but I didn’t find anything that could help me and I have no idea of how I can achieve this. I hope that someone could give me a hint about this.
Drainage basin.gh (6.6 KB)
Thanks for your help 
this is very close to what you are looking for:
There’s various threads on that: search Mesh Drainage, Drainage etc (in this or the old Forum). I have various C#'s for that but are internal. However Laurent had provided some solution(s) - if memory serves well.
Thanks for your reply @inno but I’ve already achieved that:
now I want to split the mesh in two basins (the red one and the blue one) because I need the for some calculations (min point, max point, area, ecc.)
Hello
here is a way. I used Mesh Flow from Parakeet, not sure it is the best for this task but it works in your case.
So first make a departure at each face center.
Go to the end so the step and number of iterations are important.
Group points
Then use the grouping order to group the faces.
Join the mesh “Et voilà”
As said by @PeterFotiadis there was that
Thanks Peter maybe I missed something I will search again. I just want to understand “physically” how it works. How I can find the “ridge” between the two basins.
Thanks Laurent and sorry for the useless topic.
I also used “Watershed” node from “Bison” package but it needs a point to calculate the watershed:
and I cannot understand how it works properly. I want to obtain all the basins from a mesh without specify a basin closure:
Why not using my script, just change the drainage tool for a more efficient one.
My logic is explained. So it must work if all drainage path from a basin converge to nearly the same point.
Maybe there is a misunderstanding I just wanted to apologize to have started a useless topic in the forum I didn’t want to say that your topic was useless.
No problem, I am not sure it is useless as you didn’t find a proper solution. If you manage to make one proper solution working with your data, I’ll like to see it.
Well … I do business solely via code (in most of real-life cases strictly internal stuff) so my answer would not be the right thing for you (unless you have plans to walk the C# walk - long and hilly).
In the mean time Laurent is your man (but he’s also in the C# bandwagon).
I know a bit of C# in fact I already have my own node to simulate the way how water flows downwards on a hilly terrain.
Now I want to understand the logic to implement a code to obtain a catchment area. If you want to give me a hint it will be very appreciate. Thanks
You are in the right walk: bravo.
Tomorrow I’ll post something to start (minus some internal Methods - but even so you would be able to cut the mustard).
All that assuming that you know how to deal (via C#) with Recursion, with higher order collections (DataTrees) and basic Mesh Connectivity Trees (VV and the likes)
Luca
Sorry for the delay. I’ve checked the available C#'s and all use Methods that are strictly internal … meaning that if I remove’m > bananas.
I hear you: OK but what about the hints? Well … Imagine something tough: a Hamiltonian path. That is impossible to solve without a pro level backtracing policy (otherwise you’ll end up to a N factorial solution: out of question by any means). Now … talking realistically (even on “hint level”) about backtracing without the related code is 100% pointless. Pretty much “the same” situation with the drainage thing.
this is a super interesting topic by the way…
on a pure theoretical level, the water flow is a polyline (wait, a serie of points [wait, a serie of mesh_face indices!] ) that starts from a given mesh_face_center and each time moves to the adjacent mesh face center that has lowest Z coordinate (and here maybe we could just sample the lowest point of the adjacent faces, or maybe sample the adjacent mesh face centers?)
but maybe the main point is that, for a given mesh face, any flow that gets to that mesh face and started from a higher_z_coordinate_face will just behave the same, so probably a bottom-up approach (expanding from a local minimum Z mesh face) would save a lot of efforts
and now the question, are we really interested in knowing the single flows at all? because if it’s only the basins we are after, then we could just graph the mesh using the child/parent relation of each mesh face?
as a bottom-up approach might be the most fruitful, probably it’s more a matter to find some “candidate basins”, like local minimums on the mesh, in such a way to expand our child/parent search from those starting points?
Tips:
All that given any terrain (as Mesh for speed) etc etc.
Use a Class with suitable Properties to monitor all that stuff
