Nimmt es die freie Routing-Software BRouter mit der kommerziellen Konkurrenz auf? Wir zeigen, in welchen Fällen Sie mit welchem Tool besser fahren.

Steigungen bremsen Radfahrer oft stärker aus als Umwege, nicht alle Autofahrer stehen mit dem Fuß auf dem Gas, um möglichst schnell anzukommen. BRouter bezieht im Rad-Modus Steigungen, im Auto-Modus den Energieverbrauch in die Kalkulation ein und generiert so auf den Anwender angepasste Routen.

Der Artikel “Gut geführt” [1] in Ausgabe 07/2018 beschreibt, wie Sie mit QMapShack (Abbildung 1) [2] und dem dort eingebundenen Routing-Programm Routino [3] mit wenigen Mausklicks Routen zeichnen, die einer Straße folgen. Die Software dient ebenfalls als Grundlage für diesen Artikel, der sich aber mehr auf die Fähigkeiten von BRouter konzentriert. Sie finden den älteren Beitrag als PDF-Datei auf der Heft-DVD.

Abbildung 1: Der Routenplaner QMapShack eignet sich gut, um die dank ihrer Profile äußerst flexible Routing-Software BRouter auf dem PC zu nutzen.

Seit Anfang 2017 steht in QMapShack mit BRouter [4] eine Alternative bereit, die Daten zur Höhe in die Berechnung integriert und Steigungen umschifft, wann immer es sinnvoll erscheint. Welche Umwege sich dabei lohnen, hängt von Kondition, Fahrrad und nicht zuletzt persönlichen Präferenzen ab.

Die Software gestaltet sich durch Profile sehr flexibel. Von diesen stehen direkt nach der Installation mehrere bereit, die Sie bei Bedarf an Ihre Bedürfnisse anpassen (siehe Kasten “Profile”).

Einen ersten Eindruck verschafft das für durchschnittliche Radfahrer konzipierte Profil trekking.brf (Listing 1). In dem mit ---context:global eingeleiteten Abschnitt zu Beginn stehen einige Schalter, die Sie als Anwender anpassen dürfen, um das allgemeine Verhalten der Software zu beeinflussen.

[...]
---context:global # following code refers to global config
# Use the following switches to change behaviour
# (1=yes, 0=no):
assign consider_elevation = true # set to false to ignore elevation in routing
assign allow_steps   = true # set to false to disallow steps
assign allow_ferries  = true # set to false to disallow ferries
assign ignore_cycleroutes = false # set to true for better elevation results
assign stick_to_cycleroutes = false # set to true to just follow cycleroutes
assign avoid_unsafe   = false # set to true to avoid standard highways
assign turnInstructionMode = 1 # 0=none, 1=auto-choose, 2=locus-style, 3=osmand-style
assign validForBikes  = true
# the elevation parameters
assign downhillcost = if consider_elevation then 60 else 0
assign downhillcutoff = 1.5
assign uphillcost  = 0
assign uphillcutoff = 1.5
[...]
---context:way # following code refers to way-tags
[...]

Gemäß der englischen Kommentare besteht die Möglichkeit, Treppenstufen, Fähren oder Hauptstraßen mit starkem Verkehr zu vermeiden. Auf Wunsch bleibt die Route entweder auf Radwege beschränkt oder bevorzugt sie beim Kalkulieren der Route nicht. Selbst das Berücksichtigen von Steigungen schalten Sie bei Bedarf komplett ab, was aber für Touren mit dem Fahrrad kaum sinnvoll ist.

Die Variablen uphillcost und downhillcost bestimmen, inwiefern Steigungen oder abschüssige Abschnitte die gesamte Rechnung beeinflussen. Mit uphillcutoff und downhillcutoff definieren Sie einen Grenzwert, ab dem Straßen als eben gelten. Falls das Auswerten der Höhen im ersten Abschnitt auf true verbleibt, weist der folgende Block der downhillcost den Wert 60 zu, sonst null.

Überraschenderweise steht uphillcost stets auf null, das Profil vermeidet also nur abschüssige Strecken, Steigungen hingegen nicht explizit. Die Logik ähnelt der, dass Bremsen beim Autofahren Sprit kostet, indem es erneutes Beschleunigen erzwingt.

Zusätzlich existieren laut Online-Dokumentation [5] die Variablen uphillcostfactor und downhillcostfactor, die allerdings in den Abschnitt gehören, der auf ---context:way folgt. Im Test beeinflussten sie die Route stärker als uphillcost und downhillcost.

2017 kam eine neue kinematische für Kraftfahrzeuge geeignete Funktion zum Berechnen der Kosten zu BRouter hinzu, die den Energieverbrauch nicht mehr nur über die Steigung ermittelt, sondern zusätzlich die Reibung und Beschleunigung einbezieht. Die entsprechenden Profile vom Typ car rechnen mit einem bestimmten Rollwiderstand (Listing 2, Zeile 1), Luftwiderstand (Listing 2, Zeile 2) und Gewicht des Fahrzeugs (Listing 2, Zeile 3).

f_roll = 232 # Newton
f_air = 0.4 # 0.5*cw*A*rho
totalweight = 1640 # kg

Die Profile car-fast und car-eco deklarieren diese Funktion mittels der Zeile ---model:btools.router.KinematicModel zu Beginn. Sie definieren Werte für die Rekuperation von Energie beim Bremsen und auf Strecken mit Gefälle: f_recup = 400 # Newton setzt eine Verzögerungskraft von 400 Newton bei der Rekuperation, was bei 100 km/h gut 11 Kilowatt entspricht.

Die beiden Profile sind also offensichtlich für Elektro- oder Hybridfahrzeuge konzipiert, wie es der BRouter-Autor in einem Vortrag [6] erläutert. Hilfestellungen beim Anpassen von Profilen finden Sie online [7]. Mit den Schaltern und Werten am Anfang des Skripts zu experimentieren, ist recht simpel und lohnt sich in der Praxis.

Die darauf folgende Logik zum dynamischen Zuweisen der Kosten bei bestimmten Streckentypen setzt dagegen Kenntnis der OpenStreetMap-Konventionen und viele Kilometer in der Praxis voraus. Möchten Sie sich nicht so tief einarbeiten, nutzen Sie besser die vorinstallierten Profile oder die aus dem Git-Repository von Poutnik und beschränken sich beim Anpassen auf die dafür vorgesehenen Werte.

QMapShack sowie die Android-Apps OsmAnd [8], Oruxmaps [9] und Locus Map [10] binden den BRouter ein und machen ihn auf diese Weise komfortabel zugänglich. Näheres erläutert der Kasten “Auf dem Smartphone”; dieser Artikel beschränkt sich auf QMapShack, die mobilen Apps erzeugen identische Routen.

Abbildung 2: OsmAnd errechnete im Test für Fahrradrouten mit dem Profi fastbike die gleiche Route wie QMapShack.

Der Einsatz von BRouter in QMapShack erfordert ein erstes Setup über einen intuitiven Assistenten (Abbildung 3). Außerdem ist – anders als bei Routino – kein langwieriges Aufbereiten von Daten nötig: Fertige Dateien inklusive Informationen zur Höhe stehen wöchentlich aktualisiert zum Herunterladen bereit.

Abbildung 3: Ein praktischer Wizard erleichtert in QMapShack das Herunterladen und Aktualisieren der Daten.

In trockenen Tüchern

Abbildung 4 mit Routen für Fahrräder in der hügeligen Kleinstadt Ansbach zeigt, welche Erleichterung die Software Radfahrern beschert: Die farbigen Flecken auf der Karte symbolisieren die Steigung, Orange steht dabei für 12 Prozent oder mehr. Die blaue Gerade verbindet den auf 408 Metern Höhe liegenden Ausgangspunkt mit dem Zielpunkt auf 443 Meter Höhe. Die Distanz Luftlinie beträgt 2,62 Kilometer.

Abbildung 4: Während Routino stur über die stärksten Steigungen leitet (rot) umgeht das speziell für Radfahrer konzipierte BRouter diese je nach Konfiguration auf Kosten mäßiger oder großer Umwege (blau und violett).

Die rot gefärbte Route stammt von Routino mit dem Profil Fußgänger im Modus Kürzeste. Die 3,68 Kilometer lange Strecke bezieht einen engen Fußweg ein, und nimmt keine Rücksicht auf die Form des Geländes. Auf der immer wieder mit bis zu 14 Prozent ansteigenden und abfallenden Strecke summiert sich der Anstieg daher auf 80 Meter.

Die blaue Route entstand mit BRouter und dem Profil fastbike, also für Rennräder. Sie weicht dem bogenförmigen Hügelkamm in der Mitte von Abbildung 4 aus. So ergibt sich eine Strecke von 4,35 Kilometern bei zu überwindenden 60 Metern Höhenunterschied. Mit Ausnahme eines steilen, 150 Meter langen Stücks am Anfang ist die Route durchgängig weniger als vier Prozent steil.

Im Test dauerte die Fahrt auf dieser Route knapp 16 Minuten. Bei der erwähnten starken Steigung ist der bei schwül-heißem Wetter mäßig ambitionierte Tester abgestiegen, sonst war es die meiste Zeit über möglich, entspannt ein Tempo um die 20 Stundenkilometer zu halten.

Die violette Route entstand in einem per Hand darauf getrimmten Profil, das Steigungen soweit wie möglich vermeidet. Zu diesem Zweck erhielt die Sektion ---context:way in der Profildatei die Anweisung assign uphillcostfactor = 150.

Wie sich aus der Erläuterung von Poutnik [11] zu ergeben scheint, wirkt sich der uphillcostfactor stärker auf die Auswahl einzelner Abschnitte aus, das Setzen der uphillcost beeinflusst dagegen die gesamte Wertung der Strecke.

Jedenfalls hat selbst ein Faktor 1000 für uphillcost keine so tiefgreifende Änderung der Route bewirkt, wie das Erhöhen des uphillcostfactor (Abbildung 4, violette Route im Vergleich zur blauen).

Bei einer Länge von 5,36 Kilometern weist die mit diesem getunten Profil errechnete Route lediglich 45 Meter Steigung auf, was wenig über dem Höhenunterschied von Start und Ziel (35 Meter) liegt. Die meiste Zeit über steigt die Strecke um nicht mehr als zwei Prozent an, lediglich über etwa 200 Meter am Schluss geht es mit um die sieben Prozent steiler bergauf.

Tatsächlich war die Route in der Praxis noch weniger anstrengend zu fahren, als die vom mitgelieferten Profil fastbike errechnete. Der unvermeidliche Anstieg zum Schluss überwand der Autor ebenfalls schiebend. Unerwartet lang fiel allerdings die Fahrzeit mit etwa 26 Minuten aus. Außer der längeren Strecke war dies nicht zuletzt vier Pausen an Ampeln von je rund eineinhalb Minuten im Bereich der Innenstadt geschuldet.

Quer durch

Nicht nur bei der Fahrrad-, sondern auch bei der Auto-Navigation verspricht BRouter bessere Ergebnisse als das einfacher gestrickte Routino. Das mag verwundern, denn das Auswerten von Steigungen, das entscheidende Merkmal von BRouter für Radler, spielt beim PKW keine große Rolle.

Doch seit 2017 enthält die Software eine zweite Kostenfunktion, also einen Algorithmus, der Streckenabschnitte bevorzugt oder zurückstellt. Diese kinematische Kostenfunktion stellt statt der Steigung den Luftwiderstand und die Beschleunigungsenergie in den Mittelpunkt. Sie eignet sich damit für die energieeffiziente Routenplanung.

Abbildung 5 zeigt PKW-Routen quer durch die Großstadt Nürnberg. Alle fett gezeichneten Routen stammen vom BRouter. Die dünnere rote Strecke empfahl ein aktuelles TomTom-Navi mit kostenpflichtigem Stau-Datenservice [12]. Werktags um 17:15 Uhr war die Verkehrssituation dabei in großen Teilen der Stadt angespannt.

Abbildung 5: Die fett dargestellten Routen in Nürnberg liefert BRouter mit den zwei vorinstallierten Auto-Profilen und einem weiteren aus einem externen Github-Repository. Die dünne rote Strecke liefert ein TomTom-Gerät während der Hauptverkehrszeit.

Die dünne dunkelblaue Route schlägt Routino vor, und zwar in beiden Modi Schnellste und Kürzeste: Vermutlich geht das Programm innerstädtisch von einer konstanten Durchschnittsgeschwindigkeit aus, sodass beide Einstellungen identische Ergebnisse liefern.

Zunächst fällt auf, dass sich die von BRouter mit dem Profil car-eco errechnete Route mit der von Routino vorgeschlagenen kürzesten Route deckt. Sehr wahrscheinlich handelt es sich um die kürzestmögliche Fahrstrecke von 10,6 Kilometern.

Abseits der Hauptverkehrszeiten ist an ihr nichts auszusetzen: Sie folgt Hauptstraßen, die Sie bei nicht zu starkem Verkehr zügig befahren. Außerhalb der Rush Hour würde ein ortskundiger Fahrer wohl so fahren.

Die magentafarbene Strecke entstammt dem BRouter-Profil car-fast und führt mit einem Umweg über die A73: Ihre Länge beträgt daher 15,8 Kilometer, also fast 50 Prozent mehr als die Route eco. Es sieht so aus, als sei die Software für den Autobahnanteil von der im car-fast-Profil festgelegten Maximalgeschwindigkeit von 160 Kilometer pro Stunde ausgegangen. Doch es sind in Stadtnähe nur 80 km/h erlaubt. Dies entnimmt die Routing-Software den freien OpenStreetMap-Daten offenbar nicht.

Die gelbe Route nutzt ein Profil, das BRouter nicht beiliegt, sondern aus einem externen Github-Repository stammt (Kasten “BRouter-Profile von Poutnik”). Die Strecke führt durch die Hafenregion, in der oft starker LKW-Verkehr herrscht. Abgesehen vom ersten Drittel über Nebenstraßen ist die Strecke außerdem nicht weniger staugefährdet, als die grüne car-eco-Route.

Realitätscheck

Wenigsten zwei der Routen fuhren wir daher in der Zeit um 17 Uhr in der Großstadt Nürnberg Probe: Wir wollten wissen, wie sich ein TomTom-Navigationsgerät mit kostenpflichtigem Staudatenservice (Abbildung 6) und nach Angaben des Herstellers tageszeitabhänigen Geschwindigkeitsdaten für Streckenabschnitte namens IQ-Routes [13] gegen die Navigation auf Basis freier OpenStreetMap-Daten schlägt.

Abbildung 6: Der kostenpflichtige Staudatenservice von TomTom erweist sich oft als akkurat, bewirkte aber im Test keine Wunder in Bezug auf die Fahrzeit.

Abbildung 7 zeigt eine in QMapShack nach Geschwindigkeit eingefärbte Aufzeichnung der TomTom-Route (unterer Streckenverlauf) und der Route car-eco von BRouter (obere Strecke). Da auf dem ersten Abschnitt der Route wegen Bauarbeiten ein bei diesem Startpunkt nicht zu umfahrender extremer Stau herrschte, fiel dieser Streckenabschnitt im Vergleich weg, da er die Unterschiede zu stark nivelliert hätte.

Abbildung 7: Diese nach in der Realität erzielten Fahrgeschwindigkeiten eingefärbten Routen vergleichen eine von BRouter mit einer TomTom-Navi geführten Strecke.

Zwar wurde die TomTom-Route in Gegenrichtung gefahren, was jedoch kaum Einfluss auf die Fahrzeit hatte. Dass die Fahrt mehr als 30 Minuten später stattfand, wirkt sich dagegen vermutlich nachteilig auf die Fahrzeit aus.

Die Hinfahrt auf der BRouter-Route hat durch fast durchgängigen Stop-and-Go-Verkehr sehr an den Nerven gezerrt. Die zweite Hälfte der Rückfahrt auf der TomTom-Route wirkte entspannender, obwohl es in der Hafenregion zu einer langen Wartephase kam.

Die gemessenen Werte für Fahrzeit und Spritverbrauch laut Bordcomputer eines älteren BMW 120 liegen dennoch nah beieinander: Die Fahrzeit lag für die BRouter-Strecke bei 25 Minuten, die TomTom-Route lag mit etwa 23 Minuten nicht allzu viel darunter.

Laut Bordcomputer hat das Auto auf der Stop-and-go-Route 11,6 Liter pro 100 Kilometer verbraucht, auf der flüssigeren Rückfahrt mit dem TomTom-Navi 9,4 Liter. Doch wegen der längeren Strecke liegen der absolute Verbrauch mit 0,90 Litern (BRouter) und 0,87 Litern (TomTom) dicht beieinander.

Es ist klar, dass diese Stichprobe keine exakten Messwerte liefert. Er deutet aber darauf hin, dass in einer Großstadt mit flächendeckend starkem Verkehr ein TomTom-Gerät keine wesentlich besseren Zeiten und Verbrauchswerte bewirkt, als BRouter mit den OpenStreetMap-Daten.

Dichtes Netz

Zwischen den Städten Crailsheim und Rothenburg ob der Tauber liegen viele Straßen, die als mögliche Verbindungen infrage kommen, unter anderem zwei Autobahnen und eine Bundesstraße, außerdem zahlreiche schmale und kurvenreiche Sträßchen. Ein idealer Parcours, um die unterschiedlichen Gewichtungen der BRouter-Profile für das Auto zu testen.

Die beiden bei BRouter mitgelieferten Auto-Profile errechnen für Ortskundige erwartbare Routen (Abbildung 8): Das schnelle Profil car-fast steuert die A7 an (42 Kilometer, rot), das ökonomische (car-eco ) wählt die kürzere, aber ebenfalls gut fahrbare Strecke über die Staatsstraße 2419 (34 Kilometer, dunkelgrün, anfangs deckungsgleich mit violett). Das TomTom-Navi mit in der Regel gut zutreffenden Schätzungen erwartet für diese Routen werktags gegen 18 Uhr zwischen 32 und 35 Minuten Fahrzeit.

Abbildung 8: In dieser Autobahnkreuzregion in Mittelfranken findet BRouter zahlreiche Alternativen für Autorouten. Unterschiedliche Routingprofile schlagen denn auch grundverschiedene Strecken vor.

Das Profil Car-FastEco, das Poutnik als Standard empfiehlt, schneidet zumindest in der TomTom-Prognose mit 36 Minuten knapp am schlechtesten ab (cyan in Abbildung 8). Allerdings ist sie mit 34 Kilometern nicht länger als die car-eco-Route und führt das erste Drittel über eine Bundesstraße, dann über die Landstraße 1040.

Das Profil Car-Fast von Poutnik (in Abbildung 8 magenta, bis zur A6 deckungsgleich mit cyan) setzt am konsequentesten auf schnell fahrbare Straßen: Nach einem Stück über die B290 wechselt die Route auf die A6 und dann die A7. Trotz ihrer Länge von 43 Kilometern wertet sie das TomTom-Gerät mit 30 Minuten Fahrzeit als die schnellste Verbindung.

Die Route des Car-Eco-Profils von Poutnik (gelb) deckt sich überwiegend mit der des bei BRouter beiliegenden car-eco-Profils. Es durchquert in der abweichenden gelben Anfangsphase zwei Ortschaften, weshalb das TomTom-Gerät mit 36 Minuten Fahrzeit für die 33 Kilometer rechnet.

Wie erwähnt richten sich die bei BRouter beiliegenden car-Profile mit dem Einbeziehen der Rekuperationsfunktion und einem hohen Fahrzeuggewicht offensichtlich an Elektroautos. Es liegt nahe, sie an die Physik des eigenen Fahrzeugs anzupassen.

So erhöhten wir im Profil car-fast versuchsweise die Höchstgeschwindigkeit auf 200, reduzierten das Gewicht auf 1350 Kilogramm und setzten die Rekuperationskraft und -Effizienz (f_recup und recup_efficiency) auf 0. Das so entstandene Profil errechnete dann die gleiche Route wie das Car-Fast-Profil von Poutnik.

Fazit

Nach Ansicht des Autors bewähren sich für die Auto-Navigation besonders die Profile car-fast und car-eco aus der BRouter-Standardinstallation, die sich nur in der Höchstgeschwindigkeit (vmax) unterscheiden. Allein durch das Verändern dieser Parameter lassen sie sich leicht auf noch schneller oder noch sparsamer trimmen. Es ist sogar möglich, sie den physikalischen Daten des eigenen Autos anzupassen.

Für Radfahrer liefern die ebenfalls direkt nach der Installation verfügbaren Profile trekking und fastbike gute Ergebnisse. Wer größere Umwege nicht scheut, um Steigungen zu vermeiden, fügt einfach einen hohen uphillcostfactor ein.

Die Profile von Poutnik richten sich vor allem an Mountainbiker und Bergwanderer: Sportlich Ambitionierte finden hier Varianten, die entgegen der sonst angestrebten Optimierung gezielt bergige Strecken bevorzugen.