Crossify adjustments

[3vivekb]

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?

[3vivekb]

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]

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]

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]

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?

[3vivekb]

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.