Hmm, keine Ahnung 
Bleibt nur die Frage, wie ich es anstelle, so eine Art “offizielle Fahrradwege bevorzugen” auszuwählen. Denn obwohl es nun im Bereich Wolfsanger funktioniert, führt die anfängliche Route doch wieder quer durch starken Verkehr, anstatt den auf der anderen Fuldaseite befindlichen und erreichbaren R1 zu verwenden.
Ich weiß, dass sich das mit “schnell” beißt, aber das benutzerdefinierte Profil ist mir auf die Schnelle ein wenig zu kompliziert zu verstehen. Darüber wird es vermutlich gehen, oder?
Bei Brouter Profil bearbeiten:
assign ignore_cycleroutes = false # set to true for better elevation results
assign stick_to_cycleroutes = true # set to true to just follow cycleroutes
dann bekommen die Routen mehr Punkte 
Super, danke! Ok, von selbst ging es noch nicht, aber mit einem Zwischenziel klappte es wie gewünscht.
Profil Fahrrad schnell ist für Rennradfahrer, die Straßen bevorzugen.
Profil Trekking bevorzugt Radwege und insbesondere in OSM eingetragene Radrouten.
Bei stick_to_cycleroutes = true werden dann aber “stur” Radrouten ausgewählt.
Oh, danke! Unter Trekking hatte ich etwas anderes verstanden.
Bitte, wie geschrieben gibts da mehr Punkte, also ganz ohne Via geht es nicht… aber mit deutlich weniger
Zum Verständnis: Die Punkte bestimmen die Eignung jeder Teilstrecke für das Rad abhängig von den OSM-Daten, und die Route ist dann am Ende die Zusammensetzung der Teile mit der besten Eignung und/oder kürzesten Zeit? Daher die Config-Datei, denn da ist ja viel Ermessensspielraum für den Fahrer.
Ja ein Routing-Programm muss ja irgendwie eine Endscheidung treffen was gefahren wird und dafür bekommt jeder Weg “Punkte” oder “Kosten” oder oder wie man es nennen mag… oder rechnen mag. In den Routing-Profilen werden diese Punkte/Kosten festgelegt… für alles möglichen Eigenschaften was ein Weg hat… und dann bekommt man die Route mit den meisten Punkten bzw. geringsten Kosten… 
Der Brouter hat ganz viele Profile für die unterschiedlichsten Bedürfnisse… was voll cool ist 
danke! Gibt es eine Übersicht über die verschiedenen Profile, die so leicht verständlich wie von PT-53 geschrieben sind, aber etwas ausführlicher als
“The trekking profile is for slow travel and avoiding car traffic, but still with
a focus on approaching your destination efficiently.”, “no steps”, das kann ich noch nachvollziehen: wenn man viel Gepäck dabei hat und das nicht abbauen möchte, ist das wohl relevant, aber beim Rest bin ich am Schwimmen.
trekking low traffic wäre grundsätzlich für mich interessant, es sollten trotzdem möglichst wenig Umwege gemacht werden, aber auch wenn möglich krasses `rauf und runter vermieden werden. Klar, kann ich das anhand bekannten Routen austesten, aber dennoch wäre ein Überblick manchmal ganz nett. Den Ehrgeiz, selber Profile anzupassen, habe ich nicht. Mir genügt es, die vorhandenen grob zu verstehen.
Edit: habe einen Überblick gefunden:
https://github.com/poutnikl/Brouter-profiles/blob/master/BikeProfiles/BR-Bike-Profiles-Legend.txt
Nun habe ich die Qual der Wahl…
wunschzettelschreib Das Fußgänger-/Wanderprofil dürfte auch gerne auf reine Bahnsteige routen … Eben festgestellt, dass er lieber auf der Straße daneben stehen bleibt …
… oder eben auch Bahnsteige als “Fußweg” auszeichnen. Ein Bahnsteig muss ja auch begehbar sein um in das Transportmittel zu wechseln.
“und schon klappt es mit dem Nachbarn”: https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=51.01508%2C13.66336%3B51.01312%2C13.66184
Auch wenn die Plattform als Linie erfasst wurde?
Nur nebenbei, andere Router bekommen das hin (auch wenn Plattform eine Linie ist):
graphhopper_foot:
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=48.99257%2C8.33444%3B48.99326%2C8.33536#map=19/48.99286/8.33499
osrm_foot:
https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=48.99257%2C8.33444%3B48.99326%2C8.33536
Das ist ein anderer Fall, also hier Plattform als Fläche und + Hilfsroutinglinie. (Der Fall gefällt mir recht gut.)
Nebenbei bei unseren Kollegen in Dänemark wird scheinbar die Erfassungsart als Linie (sogar wegen dem besseren Routing) bevorzugt, siehe:
https://www.openstreetmap.org/changeset/76016993
Das BRouter railway=platform nicht mitnimmt hatte ursprünglich technische Gründe, weil dadurch viele Routing-Inseln dazukommen.
Mittlerweile ist BRouter aber technisch viel besser aufgestellt bzgl. dieser Inseln, so dass ich das durchaus ändern kann. (Es passieren keine Wegpunkt-Matches mehr gegen Inseln und die bleiben nicht mehr im Memory hängen)
Die Frage ist ja auch bisschen hochgeschaukelt ( siehe https://github.com/openstreetmap/iD/issues/6409 ), so dass das ja auch ein Statement ist zu sagen, ja, alle Router routen über railway=platform…
Hallo,
ich habe BRouter als Ersatz für gpsies in der online web-Version am PC ausprobiert. Vielen Dank an Arndt für seinen Einsatz. BRouter gefällt mir ganz gut. Mir fehlen aber 2 aus gpsies gewohnte Merkmale. Im web konnte ich keine Hilfe hierzu finden.
a)
Kann man die berechnete Streckenlänge metergenau oder zumindest auf 10 m genau angeben lassen? Ist hilfreich z.B. bei kurzen Wegen zu Fuß in der Stadt zur Streckenminimierung.
BRouter rundet nach meiner Erfahrung auf ganze km auf.
Als Notbehelf schätze ich bislang über die Kilometerskala des Höhenprofil optisch den Bruchteil des angefangenen Kilometers ab.
b)
Kann ich das Routing wahlweise ein- und ausschalten und so manuell Streckenpassagen erzeugen (“Geraden” zwischen zwei manuell gesetzten Punkten); z.B. diagonal über einen Platz oder Abkürzung querfeldein zwischen zwei Wegen? Diese Funktionalität vermisse ich sehr.
Grüße aus Westfalen
Alexander
a) Die metergenaue Entfernung wird als Tooltip angezeigt, wenn man mit dem Mauszeiger auf der Kilometerzahl bleibt.
b) Gerade Linien zeichnen ist noch nicht möglich, siehe auch https://github.com/nrenner/brouter-web/issues/68. Scheint eine der am meisten nachgefragten Funktionen zu sein, gerade auch seit der GPSies-Übernahme.
Ich habe Version 1.6 released:
http://brouter.de/brouter/revisions.html
Wie immer erstmal nur als Release-ZIP. Der Update der Version auf Google-Play erst einen Patch später in zwei, drei Wochen.
Prominentestes neues Feauture ist der Delta-Update für die Datenfiles (Bisher nur im Download-Manager der Android App):
Das ist so implementiert, dass serverseitig Differenz-Dateien für die letzten 9 Tage vorgehalten werden, die im Namen die MD5-Prüfsumme der Ausgangsdatei tragen, z.B.:
http://brouter.de/brouter/segments4/diff/E5_N45/
Der Download-Manager berechnet jetzt immer erst die Prüfsumme seiner alten Datei, und wenn es dazu eine Differenzdatei gibt dann lädt er die, ansonsten wie bisher die volle Datei.
Der Update anhand der Differenzdatein ist nicht immer wirklich schnell, abhängig davon, wievele der Mikro-Kacheln Änderungen enthalten kann das einige Minuten dauern, aber das zu ladende Datenvolumen ist eben sehr viel geringer, so dass sich auch ohne schnelles WLAN die Dateien aktuell halten lassen.
Auch die Server-Instanz hinter https://brouter.de/brouter-web läuft jetzt mit 1.6. Da sind Änderungen drin an der Thread-Warteschlange und dem Profil-Cache, die ich zwar einigermassen gut getestet habe, aber durchaus noch Fehler enthalten können, also vielen Dank für’s Augen offen halten…
Gab’ auf die Vorab-Version garkein Feedback, und das habe ich als gutes Zeichen gewertet und letzte Woche schon auf Google-Play aktualisiert.
Dann gab’s allerdings eine ziemliche Welle von Leuten mit Samsung S10 und Android 10, bei denen der Download-Manager streikte (Karte zoomen und schieben geht nicht). War vermnutlich aber Zufall, weil eben das Android 10 Update für das S10 etwa zur gleichen Zeit kam.
Deswegen jetzt also nochmal eine Patch 1.6.1, der einen Workaround für dieses Problem enthält (direkter Zoom per Single-Touch). Dieser Patch ist jetzt auch schon im Playstore (aber noch im Rollout)