I have been thinking about this one for a while, but I’m not quite sure about the right approach to get this to work. The problem is as follows: I have a street network with the centrelines. I want to create the roads in this street network and the roads are off-centre relative to the street centreline.
To create the roads, I offset the street centreline to the middle of the road and then offset this line by the road width.
This is where it gets tricky: several segments do not end up meeting other road segments when the road segments are offset to the ‘outside’ despite the centrelines joining up correctly. This is to be expected and could be mediated by extending the road centrelines. They would need to be extended further for sharp angled intersections.
But on other occasions, they end up overlapping already when the road is on the ‘inside’. So they would have to be trimmed. Let’s assume I cannot just flip the curves in these cases.
There may also be edge cases where the centreline segment itself is shorter than the distance that it needs to be extended, making it more difficult to filter it out.
Thanks @magicteddy ! I’m looking into the logic you are using as we speak.
So I see you offset one end of the centreline independent from the other end and bring them together with a loft. I like that approach.
You look for the curves that are within a certain search radius from the end point of the centrelines and use that to determine the intersection of the offset lines (both should/ will be at the same position within the list).
I used a different set of curves to test with and unfortunately, it now failed.
It appears the simplify changes the list structure further down the line with the new inputs, causing the subcurve to fail. Test_Offset centrelines_new input.gh (41.3 KB)
OK, there was an issue with tree structure, I don’t know why I did not see that in the previous file.
This now works, however your set of curves has a lot of problems compared to the first one.
Some curves are not joined because they overlap…
Correct, I didn’t bother because I was expecting to use region unions to clean up the network afterwards, instead of lofting. But I wasn’t aware of the discontinuities.
I’m trying to make this really robust as to avoid drafting errors from ruining the result/ the script.
Ah, I see now why you joined the lines, because the script will extend the curves otherwise. One of the reasons why I did not is that I want to use attributes to determine the width of the street (actually I want to reference an excel sheet to get the street parameters). But that’s an additional hurdle I that has nothing to do with this problem.
I used an earlier version of the script that does the street width to generate blocks (instead of this more detailed version that I want to use to create parts of the street itself (bicycle path, road, pavement, greenery, etc.).
Exactly, and this is a problem if you have a continuous road shattered in several pieces. Now that I think about it, it could be possible to remove the adjacent curves that are tangent. That’s more code though.
Or maybe explore the possibility to group all curves that have the same width in the same branch and join them there.
Seems nice but the curves are missing (especially if they have attributes)
Some may be curvature continuous if I used Blend curves, but that’s a subset of being tangent.
I am starting to worry that the tree structures will get very hard to digest. But will see what’s possible.
I know, I am crafting up a sample Excel spreadsheet input (so you won’t have to download an additional plugin to help). I am mimicking the exact data structure. Then it’s possible to proceed on the more difficult problem where there could be both a single road segment or two (e.g. split roads or bicycle paths on both ends of the street as well).
