Ich bin vor einiger Zeit auf BRouter-Web für meine Wandertourplanung umgestiegen. Funktioniert prinzipiell astrein, allerdings bei meiner letzten Tour bin ich auf eine unschöne Eigenschaft des BRouters gestoßen. Der Routingalgorithmus hat meine Tour ohne mit der Wimper zu zucken über “via_ferrata” geplant. Ich bin jetzt kein Sonntagsspaziergänger und krabble notfalls auch mal über einen Felsen sac_scale T4, aber das ging dann doch nicht mehr: Mittelbergwand
Gibt es im BRouter eine Möglichkeit für “normale” Wanderungen ein solches Routing auszuschließen. Ich habe mal in die Profilkonfigurationsdatei geschaut, aber das scheint eine eher komplexe Wissenschaft zu sein.
selbst dann, wenn ich das Profil von bikerouter kopiere.
Beide geben den gleichen Softwarestand an, die Datendateien von bikerouter sind etwa 4 Stunden jünger.
Wenn das SAC_scale-Limit auf 3 steht (Standardeinstellung im Profil), sollten via_ferrata gar nicht erst berücksichtigt werden.
Edit: nur den richtigen Link zur anderen Instanz übrig gelassen.
highway=via_ferrata kennt BRouter bisher noch nicht. Das Problem ist hier, dass auch über unbekannte highway Typen geroutet wird.
Es gibt eine schon länger geplante, größere Änderung (#458) der verwendeten Tags (lookups.dat), in der via_ferrata auch enthalten wäre. Es macht aber vermutlich Sinn, das separat und bevorzugt anzugehen und auch die Profile entsprechend anzupassen.
Bei der Route über die Mittelbergwand (way 25292344) sieht man im Daten-Tab (Tabellen-Icon rechts oben), die verwendeten, abgeleiteten Tags highway=unknown route_hiking_lwn=yes. unknown, weil highway=via_ferrata nicht in der aktuellen lookups.dat eingetragen ist.
Für unbekannte highways gibt es im “Wandern”-Profil diese Einstellung:
assign SAC_scale_limit 3 # 0..6, 0 to avoid any SAC paths, 1 for T1 as maximum, 6 for T6 as maximum
# all paths with sac_scale higher than SAC_scale_limit are forbidden.
Allerdings ist sac_scale bei way 25292344 nicht eingetragen, sondern das separate via_ferrata_scale=2+, das wiederum BRouter nicht kennt und deshalb auch im Profil nicht berücksichtigt werden kann.
Auch die Radprofile haben einen Standardkostenfaktor für unbekannte, nicht explizit aufgeführte highways, z.B. in fastbike.brf.
… hat den gewünschten Effekt, allerdings ist die Hantierung von Custom-Profilen im BRouter-Web noch ausbaufähig. Wenn ich es richtig verstehe, soll man für jede Session dann den eigenen Profiltext herauskramen, in die Page pasten und hochladen. Das könnte man sicher hantierungsfreundlicher regeln, auch ohne dass die BRouter-Site die Custom-Profildateien dauerhaft selbst hosten muss.
Was aber trotzdem als interessante Frage offen bleibt, ist die reproduzierbare Beobachtung von @Vinzenz_Mai, dass bikerouter.de auch mit dem Standard-Hiking-Profile grundsätzlich nicht über via_ferrata routet, obwohl da doch angeblich die gleiche Routing-Engine werkelt. Vielleicht hat der Betreiber vom bikerouter das Problem schon länger erkannt und ein bisschen im Code ge-tweak-t.
Ob das, dass unknown so billig ist, aus Rücksichtnahme auf Tippfehler wie highway=residental zurückgeht? Dann könnte man das teurer machen, zeitgemäße Editoren warnen vor so etwas vor dem Hochladen und altes sollte via Osmose usw. längst korrigiert sein.
Ob das, dass unknown so billig ist, aus Rücksichtnahme auf Tippfehler wie highway=residental zurückgeht?
ich halte es für eine Fehlentscheidung, überhaupt auf „unknown“ zu routen, und dann noch so billig. Via ferratas z.B. erfordern Ausrüstung und sind mit dem Fahrrad unmöglich verwendbar, vermutlich gibt es noch mehr solcher Hämmer unter den „unbekannten“ Werten
Ich nutze den brouter sehr gerne, vor allem weil die Qualität der Routen meistens hervorragend ist. Da, wo ich unterwegs bin, gibt es halt keine via_ferrata
Außerdem finde ich das Planen im Web-Frontend sehr komfortabel.
Sehe ich ähnlich. Wenn man sich in taginfo die values zu highway anschaut, dann gibt es da einen Haufen Müll am Ende (der Liste). Ich habe mir mal eine Zeit lang die Mühe gemacht, die entsprechenden Mapper anzuschreiben, aber das hat eher wenig Rückmeldung gebracht.
Wenn Router unbekanntes komplett ignorieren ist die Wahrscheinlichkeit deutlich höher, dass tatsächlich vorhandene Straßen richtig getaggt werden und beim Rest wird halt niemand in die Irre geführt.
Ja, leider. Das zu verbessern hat eigentlich hohe Priorität, aber dann werden doch wieder grundlegende Routingfunktionen mehr nachgefragt oder es ist was anderes wichtiger.
Da kann ich nichts dazu sagen. Das ist eine komplett separate Instanz, die auch sonst ein paar Änderungen hat, die nicht im Haupt-Quellcode sind.
Dass der Steig durch die Mittelbergwand kein sac_scale trägt, das ist schon richtig. Es gibt für diesen Schlüssel keinen Wert, der die Schwierigkeiten dort erfasst. Schließlich ist die dem Schlüssel zugrunde liegende Skala für Ausweisung der Anforderungen wie sie Wanderrouten stellen erfunden worden, und auch wenn die Verwendung in openstreetmap in Details abweicht, die Wand auf dem Foto, wie viel Spaß das Durchsteigen auch machen mag, sieht mir nicht nach lwn aus
