Die Erweiterung meines RR-Profile bezüglich “smoothness” ist fast fertig, ich muss nur noch die Straffpunkte abwägen…
……………
assign smoothnesspenalty =
switch smoothness=intermediate 0.2
switch smoothness=bad 0.5
switch smoothness=very_bad 1
switch smoothness=horrible 1.5 0
…………
assign costfactor
add trafficpenalty
add smoothnesspenalty
switch and highway= not route=ferry 10000
switch or highway=proposed highway=abandoned 10000
……….
Kurze Info für OSMAND Benutzer:
Als Radfahrer ist es natürlich ratsam, den Bildschirm nur für wenige Sekunden nach einem Richtungswechsel zu aktivieren (Standard Funktion in OSMAND, um den Akku zu schonen…)
Leider wird anscheinend sehr bald die Version 3.3.3 ausgerollt, wo diese Funktion abgeschaltet wurde: Als Betatester habe ich die Entwickler darauf hingewiesen, sie versprachen lediglich, in einer künftigen Version, die Funktion wieder rein zu nehmen.
Wer die Funktion wie ich benötigt sollte 3.3.3 nicht installieren!!!
(als Umgehungslösung habe ich OSMAND+ 3.2.7 parallel zu OSMAND 3.3.3 manuell installiert / download der APK über Internet)
ich habe Dein RR-Profile mal ausprobiert. Sieht ganz gut aus. Allerdings lenkt brouter mich mich noch über ein Stück Feldweg und Kopfsteinpflaster. Könntest Du nochmal die Erweiterung posten? Vielleicht ist es dann besser. Ich check noch nicht, wie ich die Codeschnipsel einbauen muss. Eventuell auch auf Git?
Ich sende dir per Mail meine letzte Version des RR-Profile, gerne prüfe ich auch, warum ein Feldweg benutzt wird (Das lasse ich bewusst zu, wenn es etl. KM spart und schätze, dass die Oberfläche akzeptabel bleibt…)
Du kannst dabei den Preis bei Track selbst anpassen:
….
switch highway=track|road|path|footway
switch or bicycle=designated ispaved 1.2
switch isconcrete 1.4
switch tracktype=grade1
switch isfine_gravel 3 7.1
switch tracktype=grade2
switch isfine_gravel 5 11.1
switch tracktype=grade3 30.1
switch tracktype=grade4 50.1
switch tracktype=grade5 100 59
9.9
……
Schau mal in den “data” vom Brouter-web wie den Feldweg getaggt ist, dann erhöhe die Kosten nach deinem Geschmack im Profile!
Viel Erfolg
ist angekommen. Danke dafür. Sieht jetzt besser aus. Ich muss demnächst mal etwas mehr testen. Falls noch etwas “seltsam” ist, dann melde ich mich.
Prinzipiell bin ich auf der Suche nach einem Profil, welches man mit dem Rennrad fahren kann, aber hauptsächlich Radwege nimmt und nur im äußersten Notfall befahrene Straßen.
Grüße
Das neue Profile für RR-Fahrer, die befahrene Straßen nicht mögen, wurde von Saftpresse99 getestet.
Die aktuelle Version wurde nach “fastbike-verylowtraffic.brf” umbenannt.
Jetzt wäre es an der Zeit, weitere Tester einzuschalten. Im Liegerad-Forum habe ich gesehen, dass ein neuer Brouter in Entwicklung steht, und dass man es sogar testen kann: ideale Stelle für ein neues Profile?
Aber vermutlich meinst Du eher die vorherige, größere Umstellung der Oberfläche zur besseren Mobil-Unterstützung. Die gibt es aber seit Oktober auch auf brouter.de.
Danke, deine Tipps sind ganz interessant!
Mir geht es aber eher darum, das neue Profile mit meinen Radfreunden und bekannten Radvereinen zu teilen, und dafür zuerst eine einfache Möglichkeit zu schaffen, dieses Custom-Profile im Brouter-Web zu verwenden. (ohne die Aufwändigen cut/paste + Hochladen)
Dafür setzte ich inzwischen auf die folgende Entwicklung, die als nächste (Auskunft von N. Renner) geplant ist:
Eine neue Verständnisfrage ist bei einer Radtour mir heute aufgefallen:
Es geht um “route_bicycle_lcn=yes”, das vom Brouter für bestimmte Abschnitten geliefert wird.
Bei dem 1236 Meter Abschnitt wird geliefert highway=secondary surface=asphalt route_bicycle_lcn=yes
Gerne würde ich verstehen, warum der Brouter dieses „route_bicycle_lcn=yes“ liefert, und was es bedeutet.
(eine Dokumentation habe ich leider nicht gefunden. Einige Profiles werten das Parameter als „any_Cycleway aus, anscheinend sollte ich im Rennrad profile lieber nicht übernehmen)
Ich bin neu in der Brouter Welt, kante diese Relationen nicht.
Wenn ich richtig verstehe, besagt der Tag, dass dieser Abschnitt Bestandteil einer längeren Route vom Typ “route=bicycle”.
Mag diese Route schön sein!
Es gibt aber keine Garantie, dass irgendeiner Radweg exakt in diesem Abschnitt vorhanden ist?
Die Auswertung des Parameters “route_cycleway_lcn=yes” hatte ich fastbike.brf und fastbike-lowtrafic.brf übernommen, ich glaube, ich werde sie herausnehmen. Nur die Auswertung der OSM Tags selber halte ich momentan für sicher bzw. sinnvoll…
Danke nochmal für die Hilfe! (ich hatte hier wohl “cycleroute” und “cycleway” durcheinander gebracht)
Eine Frage, die in den Forums bisher leider negativ beantwortet wurde, stelle ich hier nochmal, manchmal tauchen neue Ideen auf…
In meinem Profile (Rennrad mit minimalem Verkehr) bestrafe ich Strassenabschnitte mit “maxspeed” 30 oder 50 weniger als bei höheren max-Geschwindigkeiten.
Leider sind zum Beispiel ca. 30% der highway=secondary mit dem maxspeed Attribut nicht bestückt…(Diese Info ist für Autofahrer doch wichtig?)
Hätte jemand eine Lösung? (zum Beispiel eine Möglichkeit abzufragen, ob der Abschnitt im bewohnten Bereich liegt)
Bisher habe ich nur herausgefunden, das ca. 85% der Strassenabschnitte, die mit “name=” versehen sind, maxspeed <=50 haben
(Auswertung der Abschnitte wo maxspeed vorhanden ist)
Die Auto-Profile, die das kinematische Modell verwenden, berücksichtigen ungetaggtes maxspeed innerorts, indem eine Berührung mit highway=residential am Knoten ein maxspeed=50 impliziert und das die Durchfahrt runterbremst. Aber das lässt sich für ein Rad-Profil nicht so einfach übernehmen…
Ich glaube die Zeit bringt die Lösung. maxspeed-coverage nimmt ja zu.
Andererseits ist highway=secondary maxpseed=30 ja oft ein schwieriges, enges Nadelöhr, soll man sowas wirklich suchen für ein road-bike-profil?
Hallo Abrensch,
Ja, “secondary mit 30” sind für Rennradfahrer, die allein in der Woche unterwegs sind, viel besser als ist secondary mit 100: Da überholen Autos, LKW und Busse…
Zur Zeit habe ich das Problem, dass innerorts ohne “maxspeed” die Führung (zu) weite Umwege über “residential” erfolgt.
Super Dank für die Erklärung des kinematischen Modell, auf diese Lösung muss man kommen…
Ja, leider nur im Routing Engine selber implementierbar, in einem Script wie im Brouter sehe ich keine Chance.
Leider auch meine angedachte Lösung (Prüfung ob das Highway das “Name” Attribut besitzt) funktioniert nicht:
“unknown lookup name: name”
Wäre keine perfekte Lösung, aber mit einer hohen Wahrscheinlichkeit richtig.