Grouping curves with coincident vertices

I have what should be a fairly straight forward task.

I have a list of closed curves (main list), and I want to test each curve within the main list to find the other closed curves that share a coincident vertex (neighbor curves). In the examples below if I am testing curve 0 the neighbor curves would be curves 1,3,4 and if I’m testing curve 4 all curves are neighbor curves.

The goal is to be able to call on any single curve from the main list and be returned a list of its neighbor curves. Eventually, I want to create a “periodic table” of these curves where each curve in the main list can be grouped with only its neighbor curves.

Attached is a simple example. I’m not including the .gh file because the example file is arbitrary - the curve set (main list) I will be working with is much more complex.

You didn’t post any geometry, only screen shots. :man_facepalming:

Example.3dm (16.8 MB)

I didn’t want to overwhelm :man_shrugging:

Your simple grid example is useless for the real problem you want to solve, which involves coincident edges on 12.5K of irregular shapes (closed curves) spread over a vast distance. (working far from the origin can cause problems for Rhino/GH)

Here is a way to select a subset of your 12.5K curves: (267.1 KB)

Regarding your grid question, you can check this way.
It’s certainly not for another one though… (13.0 KB)


You can internalize a subset of your curves and completely ignore the Rhino file: (423.3 KB)

Of course, neither of these posts addresses the actual problem, they merely present a realistic way of asking the question.

@HS_Kim, your code often seems to work well with his “city curves”, though not always? (438.8 KB)

P.S. Maybe if all of his curves were scaled up “slightly” (whatever that means?) from their center points so they are more likely to overlap/collide? Dicey…

1 Like

Thanks @Joseph_Oster, I had been creating sub-selections by calculating the area of all curves and then using the ‘point in curve (InCurve)’ component to reduce the total scope, but this is a much faster solution. I’m looking at the other replies you and @HS_Kim sent, thank you for your help.

This is what I had been originally working with. The portion of the definition that actually tries to do what your definitions are doing is grouped in purple and is tweaked from another post I came across and doesn’t actually do what I was trying to do, this will be much more effective to work from, thank you! (276.9 KB)
ARCH1105_Drawing_Medebach_Landuse.3dm (14.0 MB)

A little hasty with a solution, eh? And credit goes to @HS_Kim, not me.

Thank you @HS_Kim, this is very concise.

@HS_Kim, I don’t know how well your solution will work on 12.5K curves? If @gwd wants to look at only one curve at a time, it might be faster to check collisions with only the selected curve against all the others?

@Joseph_Oster I will never be using it at that scale, for the intents and purposes of the project I am working on @HS_Kim solution is great.

If that’s the case for @gwd , then it would be much easier in terms of calculations like the attached usual way. (429.4 KB)

1 Like

Very nice. I still see a few that don’t appear to be correct, like slider values 450 (one blue space, no red) and 451 (one red space, no blue) in this file ( Self-intersections, perhaps?

It seems curve 450 and 463 are duplicated…
And there are no curves collide with curve 451, so it turns out this method no longer works in such cases.
You should probably test with surfaces instead of curves for those cases…

1 Like