Project-OSRM / osrm-backend

Open Source Routing Machine - C++ backend
http://map.project-osrm.org
BSD 2-Clause "Simplified" License
6.29k stars 3.32k forks source link

traffic_light penalty to high for complex crossings (osrm v0.3.4) #1250

Open flohoff opened 9 years ago

flohoff commented 9 years ago

Hi, for example this crossing:

http://www.openstreetmap.org/?mlat=51.89652&mlon=8.36187#map=19/51.89652/8.36187

the traffic_lights controlling the foot/cycle ways also penalize the car traffic. So there is a double penalty for any traffic crossing this crossing. (Same applies to multi-lane crossing which have traffic_lights on them too - so on this crossing one passes 3 traffic_lights)

After i changed the crossing to include the bicycle/foot crossings my route monitoring showed change in routes.

http://routeqa.zz.de/?rid=13121,21896

This is a pretty old OSRM version v0.3.4 so my bug could already be obsolete but my guess was that preprocessing of traffic_lights on large crossings have not changed?

I guess there should be some logic sayed - if we had a traffic light within the last 30/50/80 meters dont apply the traffic_light penalty again - its the same junction.

Flo

emiltin commented 9 years ago

maybe first group all traffic signal by proximity, then apply a penalty only for each group passed.

another option would be to use relations that group signals in the osm. there are a few proposal, but i don't think anything is in widespread use: http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group http://wiki.openstreetmap.org/wiki/Proposed_features/intersection

TheMarex commented 9 years ago

I don't think a heuristic is a good idea. Grouping by proximity is also computationally expensive. There is actually a tagging scheme for pedestrian crossings:

http://wiki.openstreetmap.org/wiki/Traffic_light See "crossing=traffic_signals". Penalties are only applied for "hightway=traffic_signals".

flohoff commented 9 years ago

TheMarex: Still fixing the pedestrian crossings you would always pass through at least 1 - going straight you pass 2 highway=traffic_signals. This is on all junctions with seperated lanes on both streets. You have 4 intersection nodes with each of them having highway=traffic_signals on them.

flohoff commented 9 years ago

TheMarex: While reading through the page i find it VERY inconsistent tagging. We typically tag junctions or intersections to mention the type of intersection regulatory e.g. highway/railway. highway/footway. Having complex junctions the wiki page indicates we stop tagging the real intersections but instead put some traffic_signals on the ways. This is major inconsistent and when doing so as the wiki page says there is no way of really telling what the type of regulation on the real intersection is. Tagging is broken.

TheMarex commented 9 years ago

For ambiguous cases I would just tag shortly before the intersection. If you think about it, that is also what you see from a driver point of view. Each road has a traffic signal, not the crossing.

flohoff commented 9 years ago

TheMarex: I am just saying that moving the traffic_light node away from the real intersection node you loose information. And you cant get it back by heuristics.

TheMarex commented 9 years ago

You might lose information, but it is a pragmatic solution that fits to the current scheme. If you really want to fix it, you need relations to indicate that the traffic signal only applies to specific turns (e.g. the same thing we do for turn restrictions).

flohoff commented 9 years ago

TheMarex: Its not that complex. You aggregate all lights of the same junction via a relation so that the penalty calculation is able to know if passing multiple junction nodes with a traffic_light on them actually belong to the same crossing.

I amm all in favour of avoiding disambiguities in tagging. Either we tag the crossing (ALWAYS!) or we put the trafic_light node exactly where the light stands, or at the point where the "stop line" is. Right now its a mix depending of the capabilities of the mapper, documentation language, wiki page you looked at, complexity of the crossing etc.

So right now the only solution is heuristics and as you can see from this bug it fails.

emiltin commented 6 years ago

Passing 2 nodes tagged with traffic_signals in a single intersection is very common, eg:

https://www.openstreetmap.org/#map=19/55.67850/12.56462 https://www.openstreetmap.org/#map=18/55.65405/12.54236 https://www.openstreetmap.org/#map=18/55.65326/12.53908

Passing 3 nodes is also not hard to find: https://www.openstreetmap.org/#map=19/55.68201/12.55736 https://www.openstreetmap.org/#map=18/55.69667/12.52569 https://www.openstreetmap.org/#map=19/55.66816/12.60423

github-actions[bot] commented 2 months ago

This issue seems to be stale. It will be closed in 30 days if no further activity occurs.

1ec5 commented 2 months ago

I amm all in favour of avoiding disambiguities in tagging. Either we tag the crossing (ALWAYS!) or we put the trafic_light node exactly where the light stands, or at the point where the "stop line" is.

“Where the light stands” is infeasible in countries like the United States where the light is almost always at the far side of the intersection, not the near side as in Germany. I hope there isn’t any documentation recommending this approach. The other two approaches are much more common, but they have downsides too in some cases.

Ironically, this issue seems to me like an accidental feature rather than a bug: a complex intersection tends to be a larger one with a red signal phase that’s potentially significantly longer.

flohoff commented 2 months ago

We have the direction on the traffic lights meanwhile which is pretty established. The example crossings in

https://github.com/Project-OSRM/osrm-backend/issues/1250#issuecomment-360915099

i would consider tagged wrong. If there is no "single crossing node" you need to put the traffic lights basically on the stop lines - where it affects the traffic. Otherwise you have no way to avoid double/tripple penalty even with tagging the direction.

Flo