Direction go from main road and then back on one roads intersection

[tbicr]

Direction propose go out road and back again on one roads intersection (look like traffic signal penalty):

http://www.openstreetmap.org/#map=17/39.17810/-74.81747

However expected avoid this on one roads intersection.

[cepesko]

This is caused by wrong turn restriction in OSM database (node 576871182), not by osmand routing. Fixed it. However moving the traffic lights to their correct location would reduce to one signal when going North.

[cepesko]

Changed the position of traffic_lights according to Bing sat.

[vshcherb]

Yes OsmAnd uses penalty for traffic signals, that's why it is critical to not give higher priority to secondary roads.

I will mark it to another related issue with traffic signals, to revise the algorith and prevent such issues.

[tbicr]

Same issue: http://www.openstreetmap.org/#map=18/41.07095/-75.70206

Expected go through traffic signal instead U turn.

[vshcherb]

That's a typical OsmAnd problem.
Be completely clear:

1. It is OsmAnd problem that put quite a high penalty
2. It is a map problem if that manoeuvre is restricted and there is no restriction.

So I guess that is forbidden manoeuvre and it should be restriction relation.

[stephan75]

I vote for reopening this issue,
because you can reproduce this faulty routing in many places.

see map of Germany/Hamburg:

IMHO instead of adding turn-restrictions "only for Osmand" we should modify the penalties / turn costs:

give MORE penalty to those u-turns,
and give LESS penalty to traffic lights!!!

I assert that NO OTHER osm-based navigation app has these difficulties on places like in this issue thread.

What should be the reason to have NO change on penalties???? I am curious.

[cepesko]

sorry, stephan75,
but I do not agree with you in this case because of the following reason:
Osmand probably uses a "better" calculation than theses other osm-based navigations because maybe they don't take any traffic lights into account (but which is in general much less accurate).

In your case there are two details which are missing or just incorrect in the OSM-database:
1 The turn restriction is not set (so driving along there might be faster than the chance of having to wait at one of the tagged traffic lights).
2. Those two traffic lights are in fact only one and with the propper tagging [http://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction] only one would be counted.

I'll do the database correction and with the next update I'm sure you'll see that here it's not osmand's fault.
Best regards
cepesko

Edit: Did so. By the way: this major junction could use some turn:lane-tagging.... :-)

[tbicr]

Sorry, @cepesko , but for human more easy and safely wait a traffic signal than make turns:

• with traffic signal on main road I can stop + can wait max 60 sec
• with right turn I should always slow down + should go out road 10 sec + should stop + can wait to pass traffic for turn + back to road 10 sec + can stop to pass traffic to merge when no line for get speed

So:

• traffic signal can take time
• U turn can take time to pass traffic or turn at all if line not wide enough
• left turn to main road can take time to pass traffic in two directions
• left turn from main road can take time to pass traffic in one direction
• right turn to main can take time to pass traffic in one direction when no line to get speed
• for high road status (motorway, trunk, primary) I can wait more time to pass traffic than for lo status (service, residential)

[cepesko]

Edit 2: Maybe an aditional penalty for road angles between 100 and 180 could eliminate those cases where turn restrictions are still missing, since the speed has to be reduced enormously.

[cepesko]

@tbicr
you are completely right with all of your points!
The question here - for me - was only how to calculate traffic lights as best as possible.

By reducing traffic light penalty might in other cases lead you straight through the center of town instead of using the much faster urban freeway going around downtown, maybe with the same speedlimit but no traffic lights.
Therfore I would agree to the first part of what stephan75 wrote:
give MORE penalty to those u-turns,

but not:
give LESS penalty to traffic lights!!!

because it will worsen the calculation in other situations.

[tbicr]

So @cepesko , I do not know how penalties calculated for OsmAnd, but I look like you can't use only traffic signal penalty to avoid this issues, because if you avoid penalties for short turns - turns will be faster.

If a = 2 m/s^2 and traffic signal work max 60 s.
90 km/h = 25 m/s, 60 km/h = 16.6 m/s

traffic signal

to get speed from 90 to 0 or 0 to 90 we need (25 m/s - 0 m/s) / a = 12.5 s
to stop wait and get speed on traffic signal we need 12.5 + 60 + 12.5 = 85 s
without traffic signal we will pass this part in (25 m/s + 0 m/s) / 2 * (12.5 s + 12.5 s) / 25 m/s = 12.5 s

so traffic signal we pass 12.5 s to 85 s

turns

stop 12.5 s
go to turn 50 m / 10 m/s = 5 s
wait and U turn 5 s to 30 s
go back to road 50 m / 10 m/s = 5 s
get speed 12.5 s

so turns we pass 40 s to 65 s (if we not fail one of steps and OSM data will be fine :()

probability

in 10% less then - 19.7 s for traffic signal - 42.5 s for turns
in 20% less then - 27.0 s for traffic signal - 45.0 s for turns
in 50% less then - 48.7 s for traffic signal - 52.5 s for turns
in 80% less then - 70.5 s for traffic signal - 60.0 s for turns
in 90% less then - 77.7 s for traffic signal - 62.5 s for turns

turns really it took more time for me:

[stephan75]

so what can be the solution now?

Personally I think that makig a u-turn on a supermarket parking should not be the solution to save some seconds in comparison to a traffic light.

[cepesko]

@stephan75
as I mentioned before: reducing the penalty for traffic light would probably cause wrong routing in other cases (taking the route through downtown instead of taking the faster way around it)

A solution could maybe be found if devellopers
*add the extra penalty for u-turns (as you have to reduce the speed, wait,...explained by tbicr)
*include some penalty if there's a change in the type of road (perhaps depending on category: going from primary to secondary costs less than from primary to service road, aka supermarket parking)

[vshcherb]

I think I need to bring main point why traffic signals were introduce as penalty.
OsmAnd mostly uses maxspeed limitation and maxpspeed:advisory and maxspeed:practical. It assumes you can drive up to 90% of that specified speed, of course if you have 3-4 traffic lights in many cases you will not reach that speed. However on motorways and highways in the city without traffic signals it is doable.
Once we added that penalty we noticed that in many cities OsmAnd started suggesting motorways naturally without any extra and artificial coefficients. So generally speaking for ideal routing it should be always a penalty of slowing down. May be in your local situation average waiting time is 5 seconds and in other 35 seconds, OsmAnd doesn't have that data so it can't take into account. We have other issues with traffic signals already opened it is not clear if they affect that situation or not, but let's see when they are fixed.

[stephan75]

ok ... I see what you mean about traffic lights.

But then: look at the screenshots above -> do we need higher penalties for those sharp angle turns?