-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
T-shape intersections #103
Comments
There are many tricky points in this task. Let me illustrate the main idea I introduced. The process starts by computing the intersection of the boundaries of two adjacent ways (I didn't distinguish between T-shape and general intersections). This is done by the function Let me illustrate the method: Two segments of two ways are given as leaving edge vectors The construction of the buffer intersection is inspired by the motion vector in a weighted straight skeleton algorithm. The computation is adapted from the master thesis of Gerhild Grinschgl, 2016, page 39ff (it's in German). I don't explain the details here, we can do that later. The intersection point is accepted as "valid", if it is inside the normals (red lines) at the top of the edges, otherwise it is classified as "out". Using this computation, the function A next step is the construction of the connectors. This is also done for a general intersection with an arbitrary number of leaving ways. It is done in the method The three characteristic points of the connector are computed as follows. The intersection of the boundaries of the right and the center way, computed by the method described above, gives the point
This case is detected by The transition width is limited to minimal 1 m and a maximum of half of the polyline length og the center way. The point 'p' in this image is an intersection point |
But the normals to the blue and red centerlines in the second image above, do not intersect! |
This is not necessary. The intersection, computed from the red and green centerlines, gives |
It works exactly the same. Although the original idea comes from straight skeleton algorithms, I adapted the code to find the intersections correctly on the inside. The side of the intersection is determined by the order of the edge vectors (right to left). I have created a simple demo code (zip file) where you can experiment with this function. The current demo data corresponds roughly to the intersection you marked in red. |
As far as I understand it, this should work similarly with my function. You can check it by adapting the demo code. The restriction to intersect within the normals only holds at the outer ends of the edges. The idea is that there may be a next segment along the polyline that gives a better intersection. |
By the way, is there a specific reason for the negated assignment in the following line? e0u, e1u = -ev0/ev0.length, ev1/ev1.length |
Sorry, I revoke the last question. The negation is needed to have normals pointing in the same side. |
I have to process T-shape intersections in Geometry Nodes.
What are tricky points in processing them?
How do you treat the case if the widths of two collinear street sections at a T-shape intersection are different?
The text was updated successfully, but these errors were encountered: