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

Crossify adjustments #3

Open
3vivekb opened this issue Nov 11, 2017 · 5 comments
Open

Crossify adjustments #3

3vivekb opened this issue Nov 11, 2017 · 5 comments

Comments

@3vivekb
Copy link

3vivekb commented Nov 11, 2017

Crossify works great when streets and sidewalks are at right angles:
screen shot 2017-11-10 at 6 27 29 pm
works
works_2

But I feel like it doesn't work great but should work at T intersections with rounded corners:
screen shot 2017-11-10 at 6 31 21 pm
screen shot 2017-11-10 at 6 31 48 pm
should_work_2

Nor does it work well at 4-way intersections with curved sidewalks:
screen shot 2017-11-10 at 6 33 22 pm
should_work
image

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?

@3vivekb
Copy link
Author

3vivekb commented Nov 11, 2017

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?

@nbolten
Copy link
Member

nbolten commented Nov 13, 2017

Hey there!

So, the current crossify algorithm works by 'walking' down the street, moving away from the intersection, and attempting to generate one crossing using that point as the 'query center'. What actually happens is that, for example, we select the first point along the street (say 3 meters down), then ask, 'where's the closest sidewalk point on the right and on the left?', and if they are considered valid points, it generates a candidate crossing. Once a set of candidates exists, we choose the 'best' one using a cost function that looks like this:

distance from the intersection + alpha * length of the crossing. In other words, it tries to strike a balance between choosing a candidate that is close to the intersection, and also short.

alpha is currently hard-coded to 1e-1 and produces results like you see above. So, here's some options:

  1. I can make the alpha parameter user-editable when calling the command (--alpha=0.1), then we cross our fingers and hope a global variable is still fine. If you bumped alpha down a bit, it would care (relatively) more about early crossings and eventually start choosing the closer corners in that last example.
  2. We make the logic of candidate selection more complex.

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.

@3vivekb
Copy link
Author

3vivekb commented Nov 13, 2017

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?

@3vivekb
Copy link
Author

3vivekb commented Nov 16, 2017

Through testing i've determined when I set alpha = 6e-1 I get what I want as far as the point in the corner. But do you know how to make the lines straight towards the top of the T?
image

@3vivekb
Copy link
Author

3vivekb commented Nov 18, 2017

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.

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

No branches or pull requests

2 participants