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

traffic lights should incur a delay #31

Closed
emiltin opened this issue Nov 29, 2011 · 10 comments
Closed

traffic lights should incur a delay #31

emiltin opened this issue Nov 29, 2011 · 10 comments

Comments

@emiltin
Copy link
Contributor

emiltin commented Nov 29, 2011

passing an intersections with traffic lights should incur a delay.

but - in copenhagen (and probably other places too) we have green waves for bicycles: traffic signals are adjust to the speed of bikes. if you go at a typical bike cruising speed, you'll get green lights all the way. in the morning the green waves occurs towards the city; in the afternoon it's away from the city. optimally osrm would take this into account; it's these kind of things that we would like a bike route planner for copenhagen to handle.

@DennisOSRM
Copy link
Collaborator

Incurring a static delay can be incorporated. Doing it inbounds in the morning and outbounds in the evening is not easy because the osm data does not provide this information. If this data is somehow present though it may be possible to come up with a solution to this.

@emiltin
Copy link
Contributor Author

emiltin commented Nov 29, 2011

we will tag all the relevant traffic lights in copenhagen in an appropriate way.

@emiltin
Copy link
Contributor Author

emiltin commented Jan 14, 2012

seems this is implemented, but how do i adjust the penalty?

@vincentdephily
Copy link

Some crossroads are too complicated to be represented by a single highway=traffic_signal node. So a car will pass via multiple nodes, but only stop at one of them. And OSRM would count the delay twice. See http://osm.org/go/esz2LnjMP-- (currently not tagged ideally) for an example.

So I suggest that OSRM take the traffic_signals:direction=forward/backwards/both (which already has some usage in taginfo) into account, and only count the penalty if the traffic light direction matches the driving direction.

@emiltin
Copy link
Contributor Author

emiltin commented May 2, 2012

i think there are also way (maybe just proposals?) in osm for grouping signals. then the group could be counted just once, instead of each signal.

@DennisOSRM
Copy link
Collaborator

I like the grouping idea.

@vincentdephily
Copy link

Yup, relations is another scheme under discussion. I'm just worried that it would be both more complicated (many people have trouble with relations) and less flexible (I admit that I dont have a concrete example here, but some places look too complicated to be handled by a global relation).

Even tough I'd classify it as overmapping, I'll mention the possibility of tagging waiting times, traffic lights that dont affect bicycles or turning cars, etc... But we probably dont want to go there.

@emiltin
Copy link
Contributor Author

emiltin commented May 3, 2012

it comes down to the specifics. we're working on a bicycle route planner for copenhagen. traffic lights that don't affect bicycles would be relevant, as would signals with green waves for bicycles.
in any case, all this can be handled as needed by the (possibile) upcoming tag parsing script system.

@DennisOSRM
Copy link
Collaborator

Is this issue still valid?

@emiltin
Copy link
Contributor Author

emiltin commented Oct 2, 2012

seems there are a bunch of isusses discussed here. closing this, as the basic issue - traffic light penalties - is now implemented.

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

No branches or pull requests

3 participants