Skip to content
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

Match multiple parts of the route individually in case of self-intersection #79

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

PhilippMatthes
Copy link
Member

@PhilippMatthes PhilippMatthes commented Jul 15, 2024

Closes: #69

In #69 we discussed a bit about routes that intersect with themselves. This leads to the issue that traffic light geometries may not be projected onto a continuous segment of the route, impairing the matching. With this PR I propose a solution to this issue.

The idea is to split the route at the intersection point into three parts and elongate them:

  • The part before the intersection gets a 100m route section at the end, if available
  • The circle inbetween gets a 100m route section on both sides, if available
  • The part behind the intersection gets a 100m route section at its start point, if available

In this way each part keeps important shape information about the road crossing at which the intersection occurred, without cutting the geometries in the middle. See screenshot below that illustrates the overlap:

Screenshot 2024-07-15 at 13 54 04

The traffic lights matched to each individual elongated segment are combined and duplicates eliminated.

@adeveloper-wq please evaluate my possible solution with a few more examples when you are back from vacation.

@adeveloper-wq
Copy link
Member

adeveloper-wq commented Jul 24, 2024

The circle inbetween gets a 100m route section on both sides, if available

Aren't we having the same problem with invalid matches again, if we extend this part? A traffic light might gets projected on two different route segments at the intersection point. @PhilippMatthes

@PhilippMatthes
Copy link
Member Author

@adeveloper-wq yes you are right. Then we should only extrend the ingress and egress parts

@PhilippMatthes
Copy link
Member Author

@adeveloper-wq actually now that I think about it, we should cut the loop part to the length the other segments are elongated. Otherwise the projection of the loop could be interpreted as a turn, if you know what I mean

@adeveloper-wq
Copy link
Member

I just wanted to write the same. 👍

buffer = 100 # distance in meter
buffer_wgs84 = buffer / 40000000.0 * 360.0 # wgs84
for part in unary_union:
buffered = route_linestring.intersection(part.buffer(buffer_wgs84))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this part is also not really working. When we intersect the complete route linestring with the buffered segments, intersections of the route linestring are also going to lay in the buffer polygon. Therefore, the intersection of the route_linestring with the buffer polygon will likely result in a MultiLinestring for those cases. Or in a single Linestring, but where we still have the intersection in it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solution would be to elongate / shorten along the line, which is a bit more implementation work but should be easy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Restrict SG projection during SG matching on directly connected route segments
2 participants