Again routing problems because traffic lights penalties

[razor74]

Hello In the last version 2.3.5 routing is changed on tertiary roads which intersect with higher rank roads ( secondary, primary) and it has a traffic light in the crossroad or on a node on tertiary road near the crossroad. In every situation , normal route is deviate on other near road , even with lower rank, in order to avoid the crossroad with traffic lights. Like i said in the past (and like on other professional maps), traffic light MUST NOT BE interfer with routing. At least could add only time penalty until destination. But not to alter routing...

[naoliv]

It's better to provide an option to enable/disable penalties then.

[homersimpsons]

Or to get a panel to configure all penalties instead of routing.xml file

[GabrielSebastianMoise]

I confirm the problem ! Traffic light penalties must have much lower priorities, or just to calculate the time to destination. Now we have serious problems with routing , because of traffic light penalties !

Also by default to have this disabled, and who wants this option enabled, a menu to do that , is just fine !

[aceman444]

Ignoring traffic lights for routing may cause OsmAnd NOT choosing a faster route (even though longer) around a city avoiding all the traffic lights in the city centre. I have never seen the problem you guys mention. Can you provide some screenshots?

[homersimpsons]

See #2737

[naoliv]

That is why I guess it's better to offer an option to enable/disable the penalties. Then people could choose what they prefer.

[aceman444]

2737 does not seem to be a good example as the intersection is incorrectly tagged there. Please find a correctly tagged scenario.

[polarbearing]

2737 was based on a missing turn-restriction and is fixed in the data.

I had cases in Berlin/Germany where routing avoided traffic lights that were mapped twice (when crossing a dual-carriageway); fixing that to the real-world one light also fixed the routing (as found so far).

[aceman444]

Yes. Or OsmAnd getting support for something like traffic_signals:direction=forward/backward and determining which direction a stop/give_way sign applies to would also improve the situation.

[vshcherb]

@aceman444 Lots of cities like Paris http://www.openstreetmap.org/#map=12/48.8707/2.3950 etc, have a highway around the city without any traffic signals, though going straight in many times is faster by distance and by time (distance/max allowed speed), it is definitely slower in reality. So traffic signals were tested in these situations and they work much better than without them

[razor74]

There is no such "stupidity" in other well know gps navigations app like Garmin, Route 66, Here maps or even on osm dedicated like Mapfactor, Magic Earth, Maps.me etc. Like i said , traffic signal must have only a informal role for time estimation, no to influence route in a bad way. And all of these app has better and faster route calculation ( some of them calculate alternative routes very fast).

And probably beacuse of this kind of problems you remain on around 100 tousands of downloads and other has million. One of the slower app in route calculation, big problems with traffic signals, nor alternative routes, slow rendering engine, no multicore CPU support, no 3D rendering

• all after so much years... Keep going in this direction because is good...

On 25.07.2016 03:12, vshcherb wrote:

@aceman444 https://github.com/aceman444 Lots of cities like Paris http://www.openstreetmap.org/#map=12/48.8707/2.3950 etc, have a highway around the city without any traffic signals, though going straight in many times is faster by distance and by time (distance/max allowed speed), it is definitely slower in reality. So traffic signals were tested in these situations and they work much better than without them

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/osmandapp/Osmand/issues/2625#issuecomment-234812267, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVAMbfnDIHkdso_UPMR2E0kjQ-KV4Qaks5qY_96gaJpZM4Ipnb-.

[polarbearing]

My experience in Berlin, which has an outer ring and a city motorway, is that the routing aggressively goes towards the motorway, even if it is just a short section, or even if it is twice as long as using the city roads. A route on a city road is often significantly too long in time, and the ETA drops accordingly during driving.

Looking in routing.xml, I find traffic signals twice in the car profile as below, and wonder what the difference is between obstacle and obstacle_time. As the lights are reasonably synchronised in Berlin, I assume that 30 (or 30+15?) is too much for the average.

<point attribute="obstacle_time">
   <select value="30" t="highway" v="traffic_signals"/>
<point attribute="obstacle">
   <select value="15" t="highway" v="traffic_signals"/>

[GabrielSebastianMoise]

Here Maps, has a very small Traffic Light penalties. Is more a time calculation role, than route calculation !

Razor74 has a very good point. Road structure is different in Western Europe than in Eastern Europe is !

So you'll have to made 50% - 50% when you'll think in managing the route calculations !

IMHO, you are stucked in developing, and you patch up functions, damaging somethimes something, but no major changes for a long time !

It's time for optimisation, it's time to listen to others that are providing you feedback, others like me , are paying the subscription, some bought the OsmAnd+ , and so on !

I still respect your work, I can't do what you've done, but it's time to re-think a lot of things !

The Developing Management is going in a wrong way !

GooglePlay keeps the counting history !

[aceman444]

@polarbearing one of the values is for the time that should affect the routing engine and one is for the route time display. So setting the first one to e.g. 1 (almost no effect on routing) and the other one to e.g. 15 (estimate 15 seconds for the route time), should have the effect the reporter is requesting.

But try to check the routing.xml file for other values that may be relevant to your country. Check e.g. the speeds on primary/secondary/residential road. Maybe they are incorrect and therefore the motorway is "aggressively being routed to". E.g. for my country they are totally off so fixing them produces much better route estimates.

[vshcherb]

https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua#L138

[ADepic]

What happened to this? What is that link you sent @vshcherb ? Is it showing that OSMR does the same too? Bevause that doesn't do anything to improve the issue...

[ADepic]

The best way to figure out a route is simply traffic. You are just going to have to implement that

[scaidermern]

The best way to figure out a route is simply traffic. You are just going to have to implement that

"Just"? Where is this traffic data supposed to come from?

[razor74]

In this moment routing is at the worst lvl. Like was 3 or 4 years ago. Fast routing in most cases is calculated on shorter ways ( normally should be on motorway, trunk, primary roads etc.) – on low rank roads ( secondary, tertiary, residential) and shortest is calculated on trunk or primary roads, like no other navigation do... I dont use osmand anymore for navigation . Only for map editing. I’m tired to encounter unresolved routing problem, many years after first release of this software. In the meantime other software which use osm maps already has alternative routing and traffic support…

Trimis din Mail pentru Windows 10

De la: Alexander Heinlein Trimis: marți, 24 iulie 2018 14:22 Către: osmandapp/Osmand Cc: razor74; Author Subiect: Re: [osmandapp/Osmand] Again routing problems because traffic lightspenaltyes (#2625)

The best way to figure out a route is simply traffic. You are just going to have to implement that "Just"? Where is this traffic data supposed to come from? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[scaidermern]

IMHO the best approach is creating a large bunch of unit tests with all kinds of routing problems from various reported issues. Afterwards fiddle around with the weighting and penalties until all or at least most of these situations get handled correctly. Tweaking the routing algorithm without a large collection of tests won't lead to a good result.

[ADepic]

@scaidermern From opentraffic. I'm gonna email them to see if their service is still active.

@razor74

Fast routing in most cases is calculated on shorter ways ( normally should be on motorway, trunk, primary roads etc.) – on low rank roads ( secondary, tertiary, residential) and shortest is calculated on trunk or primary roads, like no other navigation do...

What???????????? I swear I have not heard anything more wrong. Osmand, in my experience, WORSHIPS high priority roads such as primary... sometimes way too much. Short routing still worships big roads to much, I have to use avoid road & and intermediate destinations to force it to use smaller roads. Osmand navigation isn't that bad anyway - plus you can use YOURS, which is online.

[scaidermern]

From opentraffic. I'm gonna email them to see if their service is still active.

Looks inactive, also mentioned at https://github.com/graphhopper/open-traffic-collection. However this list points to various alternatives. Not sure how good they really are though. Without good live data traffic information isn't worth much I guess.

[razor74]

For exaple try to load this route on osmand routing ( not osrm – osrm do a correct routing) with fast routing

https://www.openstreetmap.org/directions?engine=osrm_car&route=44.3898%2C26.1170%3B44.1669%2C24.5263#map=10/44.1881/25.3221

At least one month ago osmand did not calculate this route on primary road - (DN6). I donț know if something changes until now. This is not an isolated situation. And the map is correct from all point of views on this route. Magic Earth, maps.me and Mapfactor calculate like osrm do in this situation.

Something changes about routing in osmand last year...

Trimis din Mail pentru Windows 10

De la: ADepic Trimis: miercuri, 25 iulie 2018 12:14 Către: osmandapp/Osmand Cc: razor74; Mention Subiect: Re: [osmandapp/Osmand] Again routing problems because traffic lightspenaltyes (#2625)

@scaidermern From opentraffic. I'm gonna email them to see IG their service is still active. @razor74 Fast routing in most cases is calculated on shorter ways ( normally should be on motorway, trunk, primary roads etc.) – on low rank roads ( secondary, tertiary, residential) and shortest is calculated on trunk or primary roads, like no other navigation do... What???????????? I swear I have not heard anything more wrong. Osmand, in my experience, WORSHIPS high priority roads such as primary... sometimes way too much. Short routing still worships big roads to much, I have to use avoid road & and intermediate destinations to force it to use smaller roads. Osmand navigation isn't that bad anyway - plus you can use YOURS, which is online. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[GabrielSebastianMoise]

I can confirm issues with route calculations.

[ADepic]

@scaidermern I have sent a email to open traffic. Its quite likely they have shut down because mapzen, one of their partners shut down recently. @razor74 Examples of big roads worshipping:

Both of these get solved with fuel efficient, short routing, but fastest routing shouldn't take these massive roads all the time.

[Zero3]

Just adding some anecdata: I am working on a Denmark-specific routing.xml file, in part because I also ran into issues with OsmAnd being obsessive about staying on big roads. The following part of routing.xml under the penalty_transition block was the main cause of the issue for me:

            <select value="0" t="highway" v="motorway"/>
            <select value="0" t="highway" v="motorway_link"/>
            <select value="10" t="highway" v="trunk"/>
            <select value="10" t="highway" v="trunk_link"/>
            <select value="50" t="highway" v="primary"/>
            <select value="50" t="highway" v="primary_link"/>
            <select value="80" t="highway" v="secondary"/>
            <select value="80" t="highway" v="secondary_link"/>
            <select value="130" t="highway" v="tertiary"/>
            <select value="130" t="highway" v="tertiary_link"/>
            <select value="167" t="highway" v="residential"/>
            <select value="230" t="highway" v="service"/>
            <select value="200"/>

These values (combined with the turn penalties and other penalties in the file) make OsmAnd try too hard to stay on big roads, even if it generates significantly worse routes (in Denmark, at least). Setting all of these to 0 significantly improved routing in cities for me, so maybe try changing those values in routing.xml and see if it helps you.

[vshcherb]

This issue is very broad and is converted to discussion, some specific locations are constantly monitored and fixed