Cumulative count of intersections from two curves?

unhandled

#1

Hi everyone, I was hoping if someone could give me some ideas on how to achieve the following:
I am currently trying to find the places of most accumulation of water, to make it simple I am assuming these are the places where more streams intersect.

With an old definition @HS_Kim provided I was able to find the amount of intersections.

But I am wondering how to make a cumulative count to the river curves. (like shown in the first image).

I hope this isnt too complicated. Any insight much appreciated.

Intersections.gh (20.6 KB)


#2

You can use a tool like spiderweb to create the graph an then extract the vertex degrees, and there are other graph measurements like betweeness, Centrality, and depth that can help you get a more precise solution


#3

Ah thanks for the input, I dont work with spiderweb though, maybe there is a more orthodox way of achieving this?


(Laurent Delrieu) #4

You can make a program (C# …) to count from trunk to leaves … Is it more orthodox ? :wedding:
Counting is recursive so graph traversing is necessary.
An example here.


#5

Oh so scripting is the only way then? :sweat:


(Michael Pryor) #6

OR anemone to make loops, or a plug in that already does graphs like mentioned above.


(Laurent Delrieu) #7

Sometimes it is simplier to write script. But plugins could exist. Graph plugin could help (Spiderweb).


(Pfotiad0) #8

Indeed. Notify if you want the usual freaky stuff (a recursive dendrogram in plain English). Here’s a similar thing in action (random order curves >> ccx dendogram).

Paths (the sequel of indices, that is) in the tree shown are actually the routing to a given curve meaning … blah, blah.


#9

the general sequence that I have used on a project that is conceptually similar, modeling tree branches, is:

  • find points of all tree intersections
  • do a shortest walk, for each point, to a convenient origin
  • for each curve from the shortest walk, explode the curve into segments
  • the count of number of elements for each group of segments will be the cumulative count

as Laurent already mentioned, Daniel Abalde’s shortest walk script is a great example to follow


#10

Hi Peter, that looks very promising, I only need to find the number of accumulative intersections of the streams and draw a circle with a size that reflects that number.

The only thing I assume you need is to know where to stop counting and draw the circle.
To this I say, draw a circle at every intersection.


(Pfotiad0) #11

Get the thing (as I said classic recursion + the trick part wiith the paths acting as routes as well).

Recursion_on_Intersections.gh (144.3 KB)

In this tDot display mode you get the crv lengths (blue) plus the sum (white) of all child curve lengths (per node):

in this tDot mode you get the paths per node:

in this tDot mode you get the node depth:

BTW: Use the index slider in the Viz group to get the curve in question plus the path to arrive there.


(Pfotiad0) #12

Added just 2 lines more : now you have the child count (per node) as well + the node weight (sum of all child lengths).

Recursion_on_Intersections_V1.gh (143.7 KB)

BTW: From time to time you post stuff that is very easily addressed via code. For instance the C# posted requires about 15-30 minutes to do from scratch (but I had it already [cluster analysis etc etc]). If you know what are you doing is very easy: see how simple is the core Method for clustering the curves:

Moral: If you are after things like these (in general) you know what to do (don’t you?).


#13

Thank you Peter, I have now checked your script. And I am afraid it needs a little twist:

To clarify the direction is towards the river, this means from many nodes towards one node. I think in the script you provided is the other way around.

And also, what I really need is the accumulation count of nodes as you travel down the tree. (You start to count from the branches towards the trunk as stated above).

So once you get to the trunk a number should represent the quantity of branches in that tree. Being able to tell the biggest trees from the smaller ones.

vs


(Pfotiad0) #14

That’s one line more but I’m not at home right now … for a given node you just have to resrtict counting only to first generation (of node’s child paths in the dendrogram >> GH_Path.IsAncestor Method ).

BTW: As you travel towards the root sub-branch (towards the river [ i.e. a branch with a single dimension represending the index of the curve]) the first text Dot number is the sum of all child paths … so if you want to calculate some imaginary flow (using the second text Dot number)… blah, blah.

In any case the general solution is an object type node DataTree (with lot’s of info other than the node Point3d … like the gen 1 childs, all childs, lengths, depth, cats and dogs) .

Then you can choose anything you want to play with.


(Pfotiad0) #15

Here’s a preview of the new nodeTree (minus the stupid bug that escaped the quality control (%#$ happens) : sorry about the double node points). Not sure if I can find the time for changing some things (tDot display etc) as well (required for the new structure).


(Pfotiad0) #16

The 10 critical minutes found. Get the (bug free) thing and do whatever you want.

Recursion_on_Intersections_V1A.gh (145.6 KB)

Feel free to report any issue at: TheBigMonkeyGuru@FotiadisACMEIndustries.com


#17

Thank you Peter, exactly what I needed.

I know what to do, and in time, I will. I often find myself limited: things I want to do vs things I can do.
Recursion is such a basic but elemental feature in any scripting language. I don’t know why David left it out of grasshopper. I think at most it is sort of implicit in some components like “series”. I am starting with python and planning to move into C# then when I understand the basics. It is my understanding that once you learn any coding language you can move much easier to another.

Again, thank you for your time.


(Pfotiad0) #18

Hurry because time flies. In a few years from now (A.I. etc etc) things would change in a way that you can’t imagine.