BRouter - poor route calculation

Giulio Buccini shared this problem 15 months ago
Solved

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?

1

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.

1

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.

1

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.

1

IMHO, Brouter is an unbaked software... :( :( :(

1

IMHO, This is an unbaked opinion. :)

BRouter car routing is for testing purposes and does not have production quality. Its criticism need quality of a beta tester's analysis.

It starts with analysis of OSM data. Are OSM data correct for car case ? What are results of OSM based online routers ? How about the BRouter web cost analysis of provided and desired routes ?

BTW, as it is related rather to BRouter itself and not to usage BRouter in Locus, it should be raised in BRouter feedback resources.

1

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.

1

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?!

1

When you get strange routing, one can test OSM data interactively by shifting start and destination points toward each other along supposed and desired, but not obtained route. When the provided route suddenly switches between wrong and right, you isolated suspicious place of map where mapping may not correctly reflect reality. ( Or reality is mapped well, but is different than you think ).

Particularly, there is strange crossing going from Effnerstrasse to Isarring. Seems not possible for neither car neither bike.

1

BTW, BRouter is not a Locus addon, it is a standalone application.

1

Unfortunately, I am not that good in OSM data editing and I am at this moment unable to find out, what is wrong with that..

1

So the problem could be in the data, not in the Brouter itself. This would be a good news for me.

P.S. sorry for the wrong categorization of this post... I was sure that Brouter was some kind of add-on, shame on me.

1

Also on the official map-online service (http://www.openstreetmap.org) calculates the longer path, strange... Unfortunately I'm not enough smart to understand what is wrong with the data in that place.Also, there was no significant changes in the road on Effnerplatz and/or Effnerstrasse since many many years.

1

Wait!

by selecting Car (Mapzen) = right path,

by selecting Car (GraphHopper) = right path

by selecting Car (OSRM) = wrong path

What it means? Mmmmmh....

1

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.

1

Maybe is this the problem...

I think BRouter works fine...

1

Uh!

You have eagle eyes!

I'm not actively involved in OpenMap, there is a way to report them the problem?

1

Click on the seventh buttom on the right sidebar and write there...

1

Done. Thanks!

1

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.

1

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!