-
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
Crossify adjustments #3
Comments
Some of these situations can't be fixed where there isn't a node at the corner but perhaps it should pick the points closest to where the roads intersect? |
Hey there! So, the current
I'm open to ideas for going with the second option. We're somewhat information-limited when it comes to selecting the 'correct' location, as it's often just, 'where does the sidewalk pavement exist' when there are segments of grass on either side. |
Both options would be nice. I bet the first option would be enough, and I can tweek to see which would work for San Jose's type of intersections. But Minh and I also think the second option could also work - such as multiple candidates are generated and we just delete the ones we don't like. Deleting is so much faster than making things! Perhaps we can first try tweeking, see if it gets us somewhere, but if it doesn't we try candidate generation? |
I've written some code that adds angle of intersection of crossing and street as a factor. I'll need to parametize and test to figure out the right balance. |
Crossify works great when streets and sidewalks are at right angles:
But I feel like it doesn't work great but should work at T intersections with rounded corners:
Nor does it work well at 4-way intersections with curved sidewalks:
We have lots of t-s and 4-ways where the sidewalk ends at the corner.
Can the intersections start at the corner of the curve?
The text was updated successfully, but these errors were encountered: