BRouter - poor route calculation
Hallo,
I've just made a fresh installation of Brouter and I've tested for a while on my offline maps (by ASAMM) of the Munich city.
Brouter has a strange behaviour, sometimes calculate very strange paths, especially when the "Car" mode is selected.
For example, to go from point A (Cosimastr. 2, Munich) to point B (Occamstr. 10, Munich) it suggests a bizarre and illogical path. Why it does not consider the (big and easy) road I use every day? It could cut out many kilometers! (See the black arrow in the image below.)
Fast car mode
It is nice if you want to make a tour of the city while going to work but it makes you nervous if you just want to arrive from point A or point B.
By selecting the "Cycle" mode the things get better, but not so much. The proposed shortcut is now adopted but the big amount of bicycle-tracks in the Englischer Garten (the green zone close to the river) is ignored. A cyclist is redirected to cross a far bridge as a car...
Cycle mode
I'm missing something?
The same problem 
Giulio - I can't help with specific route, but there is a website http://brouter.de/brouter-web/ where you may experiment with same BRouter profiles with (maybe) faster/ more efficient UI for doing further testing & experiments. I hope it helps. There is also a BRF (profile) at https://github.com/utack/utack_brouter_data which I have found good for city bike routing.
Giulio - I can't help with specific route, but there is a website http://brouter.de/brouter-web/ where you may experiment with same BRouter profiles with (maybe) faster/ more efficient UI for doing further testing & experiments. I hope it helps. There is also a BRF (profile) at https://github.com/utack/utack_brouter_data which I have found good for city bike routing.
Hi Andrew,
I'm primarily interested in routing with car/motorcycle.
I was on the brouter website and I tested different profiles, no way! Somebody said that computers have no imagination but the routing algorithms provided with Brouter are a proof that they have indeed! :) :) :)
Point A = Cosimastrasse 2, Munich
Point B = Occamstrasse 10, Munich
Here below the optimal route found by google map:
The only way to get something similar with Brouter is to use the original brouter-profile called "shortest". But... it is not usable by a car/motorcycle 'cause it uses walking-paths along the road and/or other shortcuts not usable by a vehicle.
Hi Andrew,
I'm primarily interested in routing with car/motorcycle.
I was on the brouter website and I tested different profiles, no way! Somebody said that computers have no imagination but the routing algorithms provided with Brouter are a proof that they have indeed! :) :) :)
Point A = Cosimastrasse 2, Munich
Point B = Occamstrasse 10, Munich
Here below the optimal route found by google map:
The only way to get something similar with Brouter is to use the original brouter-profile called "shortest". But... it is not usable by a car/motorcycle 'cause it uses walking-paths along the road and/or other shortcuts not usable by a vehicle.
Quite curiously, the only profile working is the one called "fast-bike-asia-pacific", that is designed for bicycles:
The path is good for car/motorcyles but it is wrong for bicycles. A bicycle cannot ride on the internal "ring" surrounding the central part of the city. It is reserved to vehicles with a motor only.
Quite curiously, the only profile working is the one called "fast-bike-asia-pacific", that is designed for bicycles:
The path is good for car/motorcyles but it is wrong for bicycles. A bicycle cannot ride on the internal "ring" surrounding the central part of the city. It is reserved to vehicles with a motor only.
IMHO, Brouter is an unbaked software... :( :( :(
IMHO, Brouter is an unbaked software... :( :( :(
Routing calculations for BRouter (Bicycle-Router) is based on a combination of open-source OSM data and open-source BR profile/internal algorithm. All entered by volunteers! The quality of results is only as good as the data supplied to the algorithm. The BR web data tab may provide clues to why it has chosen a given route - see the $cost factors. It may be that specific OSM data could be improved. My experience with cycle touring is that BR is an amazing tool.
Routing calculations for BRouter (Bicycle-Router) is based on a combination of open-source OSM data and open-source BR profile/internal algorithm. All entered by volunteers! The quality of results is only as good as the data supplied to the algorithm. The BR web data tab may provide clues to why it has chosen a given route - see the $cost factors. It may be that specific OSM data could be improved. My experience with cycle touring is that BR is an amazing tool.
Hi Andrew, I subscribe your point of view: for cycling and trekking Brouter is fantastic. But for car/motorcycle is absolutely poor.
I don't think it's a problem of data. Let's take the example I've done above: to go from point A to point B the shortest way is to use a large road (it's like a motorway inside the city). If you put your starting point A on the motorway then Brouter will use it. If you move the point A far away from the motorway then Brouter will refuse to use it.
So data are there, but Brouter ignores them.
I tried of my tablet and on the brouter-web both, by using a dozen of different profiles and testing the different alternatives. No way.
A is few meters away from the motorway: wrong routing
A is placed on the motorway: correct routing
Why?!
Hi Andrew, I subscribe your point of view: for cycling and trekking Brouter is fantastic. But for car/motorcycle is absolutely poor.
I don't think it's a problem of data. Let's take the example I've done above: to go from point A to point B the shortest way is to use a large road (it's like a motorway inside the city). If you put your starting point A on the motorway then Brouter will use it. If you move the point A far away from the motorway then Brouter will refuse to use it.
So data are there, but Brouter ignores them.
I tried of my tablet and on the brouter-web both, by using a dozen of different profiles and testing the different alternatives. No way.
A is few meters away from the motorway: wrong routing
A is placed on the motorway: correct routing
Why?!
Wait!
http://www.openstreetmap.org/directions?engine=osrm_car&route=48.1533%2C11.6149%3B48.1620%2C11.5898#map=15/48.1567/11.6023
by selecting Car (Mapzen) = right path,
by selecting Car (GraphHopper) = right path
by selecting Car (OSRM) = wrong path
What it means? Mmmmmh....
Wait!
http://www.openstreetmap.org/directions?engine=osrm_car&route=48.1533%2C11.6149%3B48.1620%2C11.5898#map=15/48.1567/11.6023
by selecting Car (Mapzen) = right path,
by selecting Car (GraphHopper) = right path
by selecting Car (OSRM) = wrong path
What it means? Mmmmmh....
When I restricted the route to Effnerstrasse - Isarring crossroad, only Graphhopper found a route as turning right.
Both Mapzen and OSRM reports the route cannot be found.
In my hypothesis the routing services may use data from different timestamps. the newer data may got the mapping fixed or broken.
When I restricted the route to Effnerstrasse - Isarring crossroad, only Graphhopper found a route as turning right.
Both Mapzen and OSRM reports the route cannot be found.
In my hypothesis the routing services may use data from different timestamps. the newer data may got the mapping fixed or broken.
Maybe is this the problem...
I think BRouter works fine...
Maybe is this the problem...
I think BRouter works fine...
Aaah, I have missed that. I suppose the difference between services is, how they manage less frequent access tag values like this psv ( public service vehicles ).
The frequent approach is to define results for explicit short list of tag values. If the map tag value does not match the list, a defined default result is provided.
If the access default allows access, then route through the crossing is found. If the access default does not allow access, then route through the crossing is not found. As I suppose the OP's car is not a public service vehicle, his access should be denied, as far as OSM data are valid.
Aaah, I have missed that. I suppose the difference between services is, how they manage less frequent access tag values like this psv ( public service vehicles ).
The frequent approach is to define results for explicit short list of tag values. If the map tag value does not match the list, a defined default result is provided.
If the access default allows access, then route through the crossing is found. If the access default does not allow access, then route through the crossing is not found. As I suppose the OP's car is not a public service vehicle, his access should be denied, as far as OSM data are valid.
Hi guys, thanks all for useful discussion. There is nothing I may add ( except small tip to use OpenStreetMap Notes directly from Locus Map to simplify bug reporting ).
Thanks and have a nice evening!
Hi guys, thanks all for useful discussion. There is nothing I may add ( except small tip to use OpenStreetMap Notes directly from Locus Map to simplify bug reporting ).
Thanks and have a nice evening!
Replies have been locked on this page!