BRouter Version 1.5.5

[gynta]

Neu
v1.2 -> http://h2096617.stratoserver.net/brouter/offline.html

 

Leider wurde an der manuellen Auswahl aus den eigenen Punkten noch nichts verbessert.

[jusc]

Zusätzlich auch ab und an einen Blick auf http://h2096617.stratoserver.net/brouter/profiles2/ werfen.
Profil Trekking und die lookup.dat sind neueren Datums und werden nicht automatisch beim Update ersetzt.

[abrensch]

Daher an dieser Stelle mal ein großer Dank an Arndt für beide stabile Versionen

Bei BRouter-Web geht der Dank aber an Norbert... und natürlich an alle OSM-Beitragenden und die Autoren und Maintainer von all den Software-Libs und Diensten, auf denen das aufbaut.

Zu der Version 1.2: der Update lohnt nur, wenn man selber Profile bastelt, weil da sind Syntax-Erweiterungen drin, ein formalerer Mechanismus zur Behandlung von Initial-Kosten und eine neue lookup-tabelle mit paar mehr tags.

Dass beim Update die lookup-Tabelle und die Profile NICHT überschrieben werden, ist übrigens Absicht. Weil wer die neue lookup-Tabelle einspielt, kann alle Datenfiles wegwerfen die älter sind als ein paar Wochen. Um upzu-daten, muss man aber nichts von sonstwoher laden, einfach das "profiles2" Verzeichnis löschen, dann wird es beim nächsten Start neu angelegt mit dem Inhalt, der im APK verpackt ist.

Wer's noch nicht gesehen hat, hier das Video zu meinem Vortrag auf der Fossgis-Konferenz in Münster zu BRouter:

https://www.youtube.com/watch?v=Eba4fcYI4h4

[Christian]

Danke für die Hintergrundinformationen. Guter Vortrag.
Weiterhin viel Erfolg!

[Joachim Buhl]

Hallo Arndt

Ich hab den Beitrag auch angesehen. Interessant.
Ich bin jedoch in der Anwendung von BRouter in Locus etwas verwirrt.
BRouter erstellt doch das Routing inkl. Abbiegehinweisen mit Hilfe der OSM Kartendaten, oder?
Der letzten Folie deines Vortrages ist zu entnehmen, das Turn instructions auf der Todo Liste stehen.
Heißt das, dass BRouter garkeine Anweisungen erzeugt?
Das würde auch Folgendes erklären:

Die sinnlosen Abbiegehinweise lassen eher auf den Locus internen Hinweiserzeuger schließen.
Also der Track kommt von BRouter, die Hinweise von Locus, ist das richtig?

Danke

Gruß

[gynta]

BRouter erstellt doch das Routing inkl. Abbiegehinweisen / mit Hilfe der OSM Kartendaten, oder?

nein / und ja

Heißt das, dass BRouter garkeine Anweisungen erzeugt?

ja

Die sinnlosen Abbiegehinweise lassen eher auf den Locus internen Hinweiserzeuger schließen.
Also der Track kommt von BRouter, die Hinweise von Locus, ist das richtig?

ja

[Joachim Buhl]

Hallo

Danke, wie befürchtet.

Jetzt hab ich dann noch ein paar frustgetriebene Fragen an die deutschsprachigen Routingexperten:
1. Warum gibt es kein Routing Programm, was auf Waldwegniveau (siehe Screenshot oben) sinnvolle Abbiegehinweise erzeugt?
Sind die OSM Kartendaten auf diesem Niveau einfach zu schlecht? Es ist in die Daten bestimmt nicht soviel "Aufwand" geflossen wie in die Straßendaten für die Autonavigation. Liegt es daran?
2. Zumindest MapQuest ist leidlich in der Lage auch auf Waldwegen richtige Abbiegehinweise zu erzeugen.
Warum gibt es dann kein Programm, dass existierende GPX-Files mit kartendatenabhängigen Abbiegehinweisen versieht?
Von A nach B routen geht. Aber entlang eines Pfades? Das ist doch nur eine Frage des Algorithmus, oder?
Grobes Punkteraster auf Track erzeugen mit via points, Route generieren, Soll-Ist Abweichung zum Pfad ermitteln und ggf. Zwischenpunkte ergänzen. Das kann zwar etwas dauern aber wird doch immer schneller sein als manuelles Nachrouten.

3. Was ist der Unterschied zwischen BRouter und Graphhopper? Graphhopper scheint auf Waldwegsniveau genauso leidlich Abbiegehinweise zu erzeugen wie Mapquest. Kranken MapQuest und Graphhopper an den gleich schlechten OSM Daten?

4. Woher kommen dann in OSMand die Abbiegehinweise wenn man mit BRouter routet?

Danke

Gruß

[abrensch]

BRouter erstellt doch das Routing inkl. Abbiegehinweisen mit Hilfe der OSM Kartendaten, oder? Der letzten Folie deines Vortrages ist zu entnehmen, das Turn instructions auf der Todo Liste stehen. Heißt das, dass BRouter garkeine Anweisungen erzeugt?

Ja, gar keine. Sowohl OsmAnd als auch Locus machen aber selber welche, aber eben nur aus dem Verlauf des Tracks, ohne das gesamte Netzwerk zu kennen.

Auf der Folie stand "Turn restrictions", das meint aber was anderes (Abbiege-Beschränkungen für's Kfz-Routing)

Da stand aber auch "voice hints", und das meinst Du wohl. War aber keine "ToDo" Liste, sondern eine Ideen-Liste, der Unterschied war mir wichtig...

Ich sehe bessere Abbiege-Hinweise aber eher als einen der fehlenden Bausteine für sinnvolles Kfz-Routing (die anderen sind die Abbiege-Beschränkungen und die Zeit-Prognosen). Im Wald hab' ich da garnicht sosehr ein Problem damit.

[Joachim Buhl]

Hallo Arndt

Danke für deine Antwort.
Ja, ich meinte die voice hints. Hatte das aus dem Kopf verwechselt.

Ich halte Abbiegehinweise generiert aus dem Verlauf einer Route für absoluten Schwachsinn, speziell natürlich im Wald.
Warum benutzt man nicht die Kartendaten? Ist das so schwierig, dass das nur Navigon, TOMTOM usw. können?
Oder sind die OSM Daten so schlecht?

"Im Wald hab' ich da garnicht sosehr ein Problem damit."
Was meinst du damit?

Danke

Gruß

[zossebart]

Hallo!

Ich nutze Locus und Brouter für MTB-Touren (bastel dazu auch an einem Profil).
Das funktioniert schon ganz gut mit dem Locus-Algorithmus zum Instructions generieren. Das ist sicher auch ganz hilfreich bei heruntergeladenen Tracks, die keine Anweisungen enthalten.
Viel besser wäre aber natürlich, wenn BRouter korrekte Abbiegehinweise direkt auf dem Phone generieren würde. Dann gäbe es die Anweisungen (voice hints) wirklich nur an den wichtigen Stellen (z.B. Kreuzungen) und nicht auch bei Kurven usw.
Das wäre erstens weniger verwirrend und würde zweitens auch Akku sparen, weil das Display nicht unnötig aktiviert wird. Klar kann man die Anzahl der von Locus generierten Anweisungen auf low stellen, aber da fehlen mir dann manchmal wieder welche, ich finde das eigentlich nur auf medium einigermaßen nutzbar.
In gewissem Sinne ist der MTB-Einsatz schon ähnlich dem Auto-Navi, obwohl man sich häufig im Wald bewegt. Wir brauchen an Wegkreuzungen präzise Anweisungen über den weiteren Weg, sonst soll sich das "Navi" ruhig verhalten (bedeutet einfach weiter dem Weg folgen).
Ich persönlich würde mich deshalb sehr über eine Implementierung von "voice hints" in Brouter freuen.
Vielleicht wäre diese Diskussion aber besser in der Brouter Google Group aufgehoben?

Gruß,
zossebart

[gynta]

Ja klingt doch alles sehr einfach. Man braucht doch nur wirklich dann eine Anweisung, wenn sich in der Nähe des  Richtungsänderungspunktes auch noch ein(e) weitere(r) Weg/Straße/Pfad,... befindet.
Ansonsten einfach der Nase lang und schweigen.
Egal wie verschnörkelt der Weg auch ist.
Keine andere Möglichkeit zu fahren/gehen = Ruhe.
Abzweigung = Ansage.
Braucht man mehr? Hab ich etwas übersehen?
Warum ist das sooo schwer zu verwirklichen?

btw.
Gibt es für diesen offtopic-Beitrag eigentlich schon einen eigenen Thread?

[abrensch]

Ja klingt doch alles sehr einfach. Man braucht doch nur wirklich dann eine Anweisung, wenn sich in der Nähe des  Richtungsänderungspunktes auch noch ein(e) weitere(r) Weg/Straße/Pfad,... befindet.

Der Klang täuscht. Einmal ist es auch vom Algortithmus her bisschen komplexer. Das braucht auch ein Modell der Wege-Kategorien. Eine Autobahnabfahrt kann geradeaus gehen und ist trotzdem eine Abfahrt. Das gleiche gibts im Wald.

Dann gibt's da irgendwo eine Entfernungsskala, aber der eine Richtungs-Aenderung auch wirklich eine ist. Locus ist da schon gut und quatscht einen für "am Kreisel geradeaus" nicht so zu wie OsmAnd das tut. Um's wirklich richtig zu machen muss man aber wissen, was ein Kreisel ist.

Dann das technische Protokoll. Menion hatte mir vor langer Zeit mal was geschickt und dazugesagt, es sei alles absulut undokumentiert. Wenn sich da wirklich 2 Softwarekomponenten sinnvoll verstaendigen wollen, brauchts eine solide Schnittstellen-Definition, und ich kenne bisher keine.

Eigentlich will man ja auch mehr als nur Richtungsaenderungen, man will ja auch Oberflächen ( "in 100m links ab auf den Splittweg")

Und da könnt Ihr mir aber helfen, mir da auf die Sprünge zu helfen, welche Standards/Protokolle/Konventionen es schon gibt und was funktioniert und was nicht.

[gynta]

Ja klingt doch alles sehr einfach

Der Klang täuscht....

Hätte eigentlich mit einem Zwinker-smiley versehen werden sollen...
Natürlich ist es nicht einfach aber ich habe erreicht was ich wollte: einen Kommentar von Dir. Danke 

[Sacagawea]

Erst einmal vielen Dank an Arndt, ohne den Locus wohl kein offline Routing hätte.
Mir persönlich würden im Wald, entsprechend Gynta, einfache Anweisungen vollkommen ausreichen. Nähert sich man einer Möglichkeit anders zu fahren = Meldung, ansonsten Ruhe. Oberflächenbeschaffenheit ist im Wald erst mal Nebensache. Ist schon eine feine Sache, wenns denn funktioniert und man sich darauf verlassen kann. Ich habe das schon ein paar mal ausprobiert mit Handy in der Tasche, musste dann aber trotzdem öfters nachsehen, weil die Anweisungen zu spät oder ungenau waren.

Rudi

[zossebart]

Eigentlich will man ja auch mehr als nur Richtungsaenderungen, man will ja auch Oberflächen ( "in 100m links ab auf den Splittweg")
Und da könnt Ihr mir aber helfen, mir da auf die Sprünge zu helfen, welche Standards/Protokolle/Konventionen es schon gibt und was funktioniert und was nicht.

Leider habe ich da auch keine Ahnung 
Heißt das, dass hier jede Karten-App ihr eigenes Süppchen kocht? D.h., hast du momentan für Locus, OSMAnd und Orux jeweils die Daten-Übergabe anders implementiert?
Wie funktioniert das denn z.b., wenn MapQuest als (online) Router verwendet wird? Ich hätte gedacht, dass es da irgendeinen Standard gibt.

Ich persönlich bräuchte auf dem MTB auch nur die einfachsten Anweisungen wie links/rechts und vielleicht noch Gefahrenstelle (z.B. Bahnübergang), da es hoffentlich in Zukunft in Locus die Möglichkeit geben wird, sich das über Beeps signalisieren zu lassen. Aber das ist ja dann Sache der Navi-App, wie es die Hinweise an den User signalisiert...