BRouter: offline Fahrrad-Routing für Android

Vielen Dank für die Antwort. Hat mir weiter geholfen.

Ich hoffe mal, dass ich am ehesten mit meinem Problem hier richtig bin.

Ich habe versucht, im Tessin mit brouter, Karten von Openandromaps, Kartenstil Elevate oder Elements und Oruxmaps eine Route zu finden, und zwar auf dem anhängenden Foto von der Alpe Sinecca zum Monte Capio. Auf der Karte gibt es diesen roten bzw. schwarzen quasi direkten “Weg”. brouter routet aber oben herum und damit über neun mal länger. Wenn ich in die direkte Verbindung Wegpunkte für den brouter setze, meckert er, dass er dort keine Daten habe. Sieht mir nicht logisch aus, wenn brouter rund herum sehr wohl Daten hat.

Es scheint auch nicht an der Qualität des Weges zu liegen, denn die ist “oben rum” auch nicht anders. In den OSM Daten habe ich auf den ersten Blick auch nicht gefunden, wo das Problem liegen könnte.

Man findet die Stelle in Oruxmaps (und auch sonst) mit einer Ortssuche nach “Monte Capio”.

Ich habe ein ähnliches Problem in einem Gebirge im südlichen Südkorea.

Du willst das haben? http://brouter.de/brouter-web/#zoom=15&lat=45.91851&lon=8.23412&layer=Outdoors%20%28Thunderforest%29&lonlats=8.227043,45.914079|8.238673,45.910526&nogos=&profile=trekking&alternativeidx=0&format=geojson

Brouter ist ab unnd zu sehr sensibel, ebenfalls bei der Onlineversion, wie die Punkte gesetzt werden.

Die Gegend ist vor 3 Monaten editiert worden. Wie alt sind denn Deine Datenfiles?

Genau das hätte ich gerne offline. Am Setzen der Wegpunkt kann es doch aber eigentlich nicht liegen, denn brouter hat ja auch offline die lange Route gefunden (trotz der Option kürzeste).

Die Alps West von OAM habe ich letztes Wochenende heruntergeladen, die rd5 Dateien (so hießen die doch!?) im Prinzip zum gleichen Zeitpunkt.

Hallo Heinz-Ulrich,
ich habe es soeben probiert, alles ok. Die berechnete Strecke ist nur 1,4km lang bei 377m Abstieg. Kein deartiger Umweg wie bei Dir.
Folglich sind BRouter sowie die Openandromaps Alps_West beide auf dem neuesten Stand. :slight_smile:
Überprüfe Deine BRouter-Datei E5_N45.rd5 auf Aktualität!

Ich danke für die Mühe, die sich hier alle gemacht haben. Es hat wohl doch an der Datei E5_N45.rd5 gelegen und jetzt ist es so, wie es sein soll.

Das Problem in Südkorea war auch ein anderes. Nicht in den OAM dafür aber in Online Karten von OSM habe ich zu dem Pfad mit dem Problem eine Anmerkung “no trail” gefunden. Wenn ich einen Punkt auf einem Weg ohne diese Kennzeichnung gesetzt habe, hat brouter auch dort eine Route gefunden.

Hallo,
ich nutze brouter mit Osmand. Mein Problem ist nun ich habe nogo Punkte festgelegt, diese werden jedoch nicht beachtet, sondern trotzdem angefahren. Woran kann das liegen? Auf dem Tablet funktioniert es, auf dem Handy (Sony Xperia L) leider nicht.

Wahrscheinlich daran, dass Osmand als “coordinate source” überhaupt nicht gefunden wird.

Wird die OsmAnd Favoriten-Datenbank denn gefunden, wenn Du die BRouter-App startest und da einen Startpunkt auswählen willst?

Wenn nicht, kannst Du in der Datei segments4/storageconfig.txt den Pfad zum OsmAnd-Verzeichnis eintragen, analog der Vorlage dort.

(und nicht vergessen, das #-Zeichen, das diese Vorlage auskommentiert, zu entfernen)

Wie kann ich die Datei denn ändern? Über PC kann ich nicht drauf zugreiefen und mit dem Handy kann ich sie nur ansehen undnicht ändern.
Wie kann ich denn hier Screenshots/Fotos hinzufügen. Dann würde ich die Datei mal zeiegn, ich weiß nämlich auch nicht genau was ich ändern muss.
Vielen Dank für die Hilfe.

Ergänzung:
Ich habe es jetzt hinbekommen. Es läuft wieder. :slight_smile:

Ich hab’ heute die Version 1.4 hochgeladen (noch nicht in Google-Play):

http://brouter.de/brouter/revisions.html

Wichtigste Ergaenzung ist die Generierung von Abbiegehinweisen.

Zur Zeit macht das am meisten Sinn, wenn man in Locus-Maps manuell GPX-Tracks importiert, die mit der BRouter-App berechnet wurden. Man kann sie auch über http://brouter.de/brouter-web/ berechnen, muss dann aber das Profil ändern auf turnInstructionMode = 2
(Die BRouter-App weiss selbst, dass sie für Locus generiert, wenn die Wegpunlktdatenbank aus Locus kommt)

Neben turnInstructionMode = 2 = locus gibt’s noch 3 (osmand), und (undokumentiert) 4 = Kommentar-Syntax und 5 = “gpies-Stil”,
aber letzters ist nicht getestet, also keine Ahnung, wie man brauchbare Abbiegehinweise in ein Garmin bekommt.

OsmAnd bisher auch nicht ganz sauber, weil der notorisch meine “Geradeaus” Hinweise verschluckt, da wirkt offenbar ein Filter, der sie bereinigt, wenn sonst die Hinweise zu diicht sind.

Geradeaushinweise generiere ich z.B. beim Queren einer höherwertigeren Strasse, oder bei einer Winkel-Störung, wo netto aber kein Winkel rauskommt, etwa wenn’s von einer Strasse auf den strassenbegleitenden Radweg geht (oder umgehkehrt).

Über die Service-Schnittstelle kommen diese Hinweise zur Zeit weder in Locus noch in Osmand, aber ich stehe mit Menion (dem Autor von Locus) in Verbindung und hoffe, dass sich das zumindest für Locus bald ändert. Und ausserdem, dass ein Bug in der Ansage von Kreiseln behoben wird (bzw. der Ansgae von normalen Turns nach einem Kreisel). Dieser Bug ist zurzeit noch so bisschen ein Spielverderber.

Die zweite wichtige Ergaenzung ist ein erweiterter Scan nach Maptool-Installtionsverzeichnissen, um genau solche Installtionsprobleme zu addriessieren, wie sie Brina81 im vorangegangen Kommentar beschrieben hat. Ich weiss noch nicht, wie gut das in der Praxis fumktioniert.

Freu mich wie immer über Feedback. Und ich werde hier wieder posten, wenn’s auch den erhofften Locus Update gibt.

Gruss, Arndt

Liegt es an brouter oder an den OSM Daten oder den openandromaps, dass brouter hier https://www.openstreetmap.org/way/216267268 über eine Straße routet, die erst im kommenden Jahr im Mai fertiggestellt sein wird?

Ich habe einen Ausgangspunkt im Stadtteil Kaßberg von Chemnitz und ein Ziel in der Stadt Marienberg/Erzgebirge und die Route führt die ganze Fraunhoferstraße lang, die aber bislang (und teilweise schon geraume Zeit) nur im nördlichen Teil fertig ist. Der südliche Teil ist noch im Bau und zwar so, dass dort an Fahrradfahren wirklich nicht zu denken ist.

Über highway=construction sollte nicht geroutet werden, also Fehler im Brouter.

Hallo Heinz-Ulrich Schwarz,

gib doch mal Dein Start- und Zielort im BRouter-Web-Client ( http://brouter.de/brouter-web/#zoom=13&lat=50.8247&lon=12.8967&layer=OpenStreetMap ) ein und Zeige uns das Ergebnis (nach Berechnung der Route rechts unten auf Permalink klicken und dann die generierte URL als Link posten).

Grüße
Peter

http://brouter.de/brouter-web/#zoom=16&lat=50.80542&lon=12.92529&layer=OpenStreetMap&lonlats=12.925286,50.824441|12.925029,50.803548&nogos=&profile=trekking&alternativeidx=0&format=geojson

Den Link habe ich noch einmal ausgetauscht, hatte in brouter-web eben shortest gewählt, das ist aber wohl für Fußgänger und ich hoffe, dass trekking fürs Radfahren ist - oder?

Dabei habe ich allerding Anfangs- und Endpunkt nicht nach meiner ursprünglichen Route gesetzt, sondern auf dieser Route (Ergebnis von brouter auf dem Tablet) kurz vor und hinter die Fraunhoferstraße. Wird auch durch die Baustelle geroutet.

Mit dem car-Profil wird um die “Baustelle” herum geroutet. highway=construction wird im PKW-Modus also berücksichtigt / ausgeschlossen. Für das Radrouting (trekking) über die Fraunhoferstraße dürften die Einträge sidewalk=both und / oder cycleway=lane verantwortlich sein. Ob diese Eingaben an einem highway=construction so korrekt sind oder ob hier wirklich ein Bug in brouter vorliegt, kann ich nicht sagen. Warten wir was Arndt dazu sagt.

Grüße
Peter

Danke, ich finde das wirklich immer super, wie schnell hier auf Probleme eingegangen wird.

Hallo BRoutergemeinde,

ich habe da mal ne (blöde?) Frage. Was genau bedeutet eigentlich beim WebClient bzw . beim Offline-Routen

Ascend filtered
Ascent plain

genau?

Zum Beispiel bei der gleichen Route in BRouter Ascend filtered~ 535m und bei GpsMaster gross rise~ 859m…

Ich meine nicht die reine “Übersetzung”. Zum Teil weichen da bei der Auswertung die Tools bzw. beim GPS Tracking die Angaben (Steigung) erheblich voneinander ab.

Vielen Dank
Achim

Ps: Übrigens funktioniert das (pure) OfflineRouten mit dem Webclient / BRouter-Server / Mobac MapsforgeSRV mit den Obenandromapkarten sehr gut. Beide Server kann man in der Config konfigurieren.

Hallo Achim,

es gibt keine blöden Fragen - aber wer nicht fragt, bleibt blöd :slight_smile:

Der “plain” ascent, ist der einfache, mathematische Höhenunterschied zwischen Anfang und Ende der Route (kann + oder - sein, Aufstieg oder Abstieg).

Der “filtered” ascent, ist der tatsächliche Anstieg - also die (positive) Summe aller Aufwärtsbewegungen.

Allerdings hat jeder Algorithmus zur Berechnung des Anstiegs, seine eigene Filterfunktion - der eine besser, der andere schlechter - je nach Anwendungsfall. Exakt genau KANN keiner sein. Beispiel:
Du fährst auf einer exakt ebenen Fläche. Durch Messfehler / Toleranz / atmosphärische Störungen z. B. Druckschwankungen bei barometrischen Höhenmessern, durch vorbeifahrende LKW etc., springt die gemessene Höhe um +/- 2 m hin und her - obwohl sich deine Höhe überhaupt nicht ändert. Die Kunst eines Filters ist es, solche Schwankungen z.B. durch einen Tiefpassfilter herauszurechnen. Das macht jeder ein bisschen anders - daher sind unterschiedliche "Anstiegs"angaben bei unterschiedlichen Routern/Geräten ganz normal. Du kannst einen einstellbaren Filter verwenden z.B. GPSPrune, dort kannst du einen GPX-Track einlesen, einen Bereich markieren und dann die gewünschte Höhentoleranz des Filters manuell einstellen (Einstellungen => Altitudtoleranz)

Schöne Grüße