I have tried similar script based on removing the duplicates resulting the same issue in one specific area (The surface inside the yellow circle must be removed as well).
1 Like
That’s the way I have had also in my mind and end up at same place like you “how to implement in GH” 
Wow, you really went there I’m afraid my GH knowledge is out of this concept but I’ll take a deeper look on it, thanks.
terrain_generation_for_laser_cutting_FF2.gh (2.8 MB)
I was thinking something similar, but I had to sleep too before having any chance to do anything good.
you pick the curve in layers from 0 to n-1 and check vs every next layer of surfaces (from 1 to n) to cull surfaces (cull surface above the points on curve)
for the first layer you do the opposite: check curve in layer 1 vs surface in level 0 and take surfaces below the points on curve
3 Likes
Actually, there’s no need to check each curve against every layer above, only the next layer above. That makes things much easier, and we shouldn’t get into too much trouble with overwhelming numbers of intersection checks. Let’s see how this goes…
I figured out that you not only have to set up manually the lowest layer, but you will miss every internal valley (if there are any).
If you do the opposite (taking points and looking down) you have the same problem with top of hills
so I think the correct way to ensure picking everything automatically is doing both and then merging (see the script for more explanation)
1 Like
This works perfectly on testing model, thank you very much. I assume you used a similar idea @Tom_Newsom suggested. I’m struggling to apply your script on the final complex model.
This looks very promising. Let me take a look closely. Thank you
something will fail but that’s because the curves in the upper right corner (looking from top XY) are not closed or not touching with both endpoints the border, so they dont cut and generate any surface (on the left in the image)
1 Like
I can’t run yours due to plugins, but I got there too
This is all vanilla GH:
terrain_generation_TN4.gh (2.8 MB)
It works exactly like my sketch, and can go bottom up or top down (output is reversed, and neither direction is quicker than the other). To handle the last layer, I flipped the boolean of the intersection result. There’s probably a smarter way but it works and takes no time
Thought I had it solved then spent ages hunting down a bug that ended up being bad data! All the contour lines must be closed or touch the boundary. These ones in the top right don’t:
(my quick fix shown there in red)
EDIT: I see you found it too. I suspect both our solutions are very sensitive to data quality. I know mine will fail if you delete a contour from the middle of the stack.
2 Likes
Yeah, I’m sorry for the missing data. It’s because the rectangular region intersect the national border. Anyway, I applied your workflow on complete region (national border included). And it works pretty well it just seems it does not work properly on the top of the hills (red curves).
they look like another edge case: a small hill cutted by a single plane, so the surface it’s not seen either going down from a point on curve above or going up from a point on curve below.. I didn’t consider it. maybe @Tom_Newsom had better result. When I have more time I’ll think about it and also take a look at Tom’s solution
1 Like
Mine picks up the tops of peaks if you put it in Look Up mode
and vice versa for Look Down
So we should be able to integrate both…
(the brute force way would be to duplicate the entire graph. the “correct” way would be to provide 1,-1 as a list of inputs to look up/down variable, but that would almost certainly ruin the data structure)
EDIT: or by finding single-loop Brep Edges that exactly match a loop in any other Brep…
1 Like
Oh for crying out loud, there’s an island in an island 
Is there any chance you could move the project to somewhere with more compliant geography? 
2 Likes
I have created a new thread to solve the island problem, as it’s of general interest:
1 Like
Fixed it, with some kludged-on post-processing. If I’d known about Boundary Surface behaviour with nested curves, I might have gone about the whole thing differently. Ah well.
terrain_generation_TN5.gh (2.8 MB)
Not sure I follow or if my attempt was that similar, but it definitely wasn’t the real deal given we were too early in the process with your ‘test’ file anyway 
So, I discarded my (flawed) ‘sort-by-segment-count’ idea, and though I admire the attempts presented by @Tom_Newsom and @Fabio_Franchetti, I remained stubborn in my {later} mission to stay away from Surface Split to favor speed via a curve-only workflow.
Open the definition and you’ll see it’s not slow as before when we were splitting surfaces.
As we all know, the naughty contours are still the naughty contours, regardless:
As they don’t intersect the boundary adequately (only one endpoint touches the boundary, but both should?) or they don’t intersect at all.
For that matter, I’ve left the ‘contour management filter #4’ (light red group) as a place-holder, as I am not sure how you plan to go about the missing contour data—but please notify and I can adjust the script:
Summary of contour management filters:
#1: distinguishes closed vs open contours
#2: splits tree based on intersection quality
#3: splits boundary & joins w/ corresponding contour
#4: place-holder group (currently just pulling end points to boundary, I’ll wait for your commentary)
File:
terrain_generation_crv-quality-mgnt.gh (2.8 MB)
Cheers and thanks!
I could but would it be still fun? 
Not sure what have you fixed exactly but there are some missing layers.
Love your honest captions in the script
I really appreciate you tried to fight the incomplete data. It seems your script fails in the top left corner of your provided screenshot. Anyway, if you are still willing to play and help me to solve the problem see the attached (complete) data file with contours touching the borders all the way around.
1 Like