Namenskonvention für No-Go-areas wäre schon möglich, aber einer Route fest zuordnen würde ich die nicht. Ohne Änderung wäre die Darstellung alles andere als intuitiv und das dahingehend zu überarbeiten per Konvention erkannte No-Go-Punkte einer Route anders darzustellen gefällt mir gar nicht (da bestimmt dann der Workaround das Konzept…). Für Sperrzonen sollte man schon das Datenmodel der Routen konzeptionell erweitern und No-Go-Areas separat bearbeitbar und dann einer Route hinzufügbar machen. Man will die Areas ja auch irgendwo sehen. Ein weiteres Problem mit der Namenskonvention ist, dass man in QLandkarteGT ‘Ad-hoc’-routen nicht notwendigerweise aus existierenden Wegpunkten, sondern viel einfacher über ‘Overlay’->‘Entfernungsmesser’->‘Route erzeugen’, das geht deutlich einfacher als erst mal für alle Zwischenziele einen Wegpunkt anzulegen. Nur kann man die Punkte der damit erzeugten Route nicht individuell bearbeiten und auch einer so dynamisch erstellten Route keine weiteren (existierenden) Wegpunkte hinzufügen.
Aber vieleicht muss man die NoGo-punkte überhaupt nicht einer bestimmten Route zuordnen, sondern einfach ‘global’ verwalten. In QLandkarte hat man ja immer eine Workarea in der man arbeitet. Eigentlich fehlt den Punkten dann nur ein optionaler Radius und ein ‘Go/NoGo’-flag, dann könnte man diese als Kreise darstellen und einfach alle in der Workarea befindlichen NoGo-punkte beim Routenberechnen (unabhängig von der konkreten Route) mitschicken.
Ich denke aber, dass ich das eher in QMapShack, dem in Entwicklung befindlichen Nachfolger von QLandkarteGT angehen werde. Da passt das konzeptionell viel besser rein, weil man mehr als eine Workarea zur gleichen Zeit offen haben kann. QMapShack ist schon sehr weit gediehen und was die Bedienung (gerade beim Routenerstellen) angeht auch einfacher zu bedienen als QLandkarteGT.
Wir könnten Requests von BRouter-Web z.B. über den “Origin” HTTP Header ableiten und entsprechend loggen (gegen Apps die Header faken hilft das allerdings nicht).
QLandkarteGT könnte einen “User-Agent” HTTP Header mitschicken, idealerweise mit entsprechender Version, z.B. “User-Agent=QLandkarteGT 1.7.7”.
Das liegt an meiner Gewichtung. Aber mir ist da aufgefallen, deine Onewayregelung berücksichtigt nicht, ob Bürgersteig oder nicht. Und damit, ob man schieben kann oder nicht. An so einer Stelle habe und möchte ich als Radfahrer schiebenderweise nichts zu suchen haben.
Aber solche Übergänge gibt es viele, wenn es oberirdische Schienenfahrzeuge entlang der Straße gibt.
Diese relaxte Oneway-Penalty mit nur Faktor 4 (=fussgeschwindigkeit) mache ich ja auch explizit nicht für primary/secondary/tertiary highways, da sind (im trekking-profil) die faktoren viel höher, nämlich 50/30/20.
Um also auf einer secondary 200m gegen die Einbahnrichtung zu routen, muss es keine Alternative geben, die weniger als 200m*30 = 6km Umweg darstelt, und das ist schon sehr selten und dieser Faktor 30 soll eigentlich nur verhindern, dass bei tatsächlichen Mapping-Fehlern an einer Kreuzung nicht wegen 3 Metern in falscher Richtung das Netz zerschnitten wird.
Ich habe das vermutlich mit meinem extremen Routingeinstellungen herausgekitzelt.
Aber
als 200m*30 = 6km Umweg darstellt, und das ist schon sehr selten
ist in Schweden ziemlich gut möglich, bei Europastraßen mit neuem Layout. Zweispurige Straßen, mit keinem Seitenstreifen, aber Geländer und kilometerlange Absperrung des Mittelstreifens.
Ich für meinen Teil werde die Strafen hochdrücken.
An deinem “selten” stört mich etwas. Ich persönlich bin der Meinung Fahrradrouting ist länderspezifisch. Was mit den Einstellungen in einem anderem Land passieren kann, weiß man nicht. (Ich habe in UK ein paar lustige Erlebnisse mit meinem Routing, was in D gut funktioniert, gehabt). Deswegen bin ich der Ansicht, es gibt (sicherheitsrelevante) Dinge die dürfen nicht selten passieren, sondern gar nicht.
Und Schieben gegen eine Straße ohne Ausweichraum, wenn Laster mit 100 entgegenkommen gehört meiner Meinung dazu. Wenn sich das jemand selbst einbrockt in Ordnung, aber Du solltest einem das nicht einbrocken.
Hallo,
vorab erst mal mein Dank an den Brouter Autor. Ein hervorragendes, einzigartiges Programm hast du da geschaffen. Klasse. Bereitet mir viel Freude.
Auch wenn es in diesem Thread um das Fahrradrouting geht, poste ich meinen eigentlich aufs Motorradfahren bezogen Beitrag hier, weil ich nicht weiß, wo sonst. Sorry fürs OT.
Mein Anliegen: Ich versuche, ausgehend von der Profildatei moped, ein Profil für kurvenreiche Motorradstrecken zu erstellen. Dabei habe ich zwei Probleme:
Wenn ich turncost auf 0 setze, erreiche ich zwar, dass kurvenreiche Strecken gleichrangig mit geraden Strecken bewertet werden, nicht aber, dass sie explizit bevorzugt werden.
Gleiches gilt für Strecken mit Steigungen. Diese würde ich gerne bevorzugen.
D.h., die Eigenschaften einer Strecke, die ich gerne bevorzugen würde, kann ich in der Profildatei allenfalls “nicht benachteiligen”. Ich sehe auch keine Möglichkeit, ebene oder gerade Strecken zu identifizieren, um sie dann zu benachteiligen.
Was ich mir wünschen würde, wäre also eigentlich, dass turncost und *hillcost negative Werte akzeptieren, also den costfactor vermindern.
Mit den Kurven ist nicht so einfach. “turncost” ist auf Kurven garnicht sensitiv, eher auf Ecken.
Was man hier bräuchte ist eine neue, dynamische Variable, die z.B. die Geschwindikeit von einem hirnlosen biker beschreibt, der immer so schnell fährt, wie er kann. Diese Geschwindigkeit muesste man aus dem Kurvenverlauf entlang des Pfades ausrechnen. Und dann kann man einen Strafterm einführen, wenn die Geschwindigkeit zu hoch wird (die Strecke also zu gerade)
Interessanterweise habe ich über sowas vor einem Jahr schonmal nachgedacht, als ich über energie-optimiertes Routing fuer E-Autos nachgedacht habe, da braucht man naemlich auch genau diese Physik…
Mittlerweile gibt es die Releaseversion und es funktioniert problemlos. Zugegeben hatte ich etwas gebraucht, um zu verstehen, dass man Routen erst “erzeugen” und dann noch “berechnen” muss, aber wenn man das einmal weiss ist es kein Problem mehr.
In Osmand gibt es ja das Entfernungsmessungstool. Die abgemessene Strecke kann man als gpx-track speichern. Wäre es möglich das Brouter anhand solch eines Tracks routet, wenn so ein Track einen bestimmten Namen bekommt.
Warum fände ich es praktisch? Bei dem reinem Setzen von via-points ist es bei längeren Routen ziemlich schwer zu sagen wie lang eine Strecke wird. Also auf Radreisen wäre es praktisch. Mit dem Entfernungsmesser hat man zumindest einen groben Richtwert.
Ich habe mich mit den NoGo-Areas im Webinterface beschäftigt. Es sind Kreise mit harten Kanten. Ich persönlich glaube man verwendet die Kreise stillschweigen in der Hoffnung, dass der Weg z.B. hoffentlich rechts um den Kreis geht. Dummerweise kann der Weg ziemlich dann doch weit links an dem Kreis vorbei laufen.
Ich glaube bei einer Langstrecken Planung sieht man eine Art Kanal auf der Karte und in diesem Kanal will man seiner Defintion gemäß anständige Wege. Das geht noch so einigermaßen mit den Nogoareas im Webinterface, aber in den AndroidApps wird es schwierig:
weil der Kreis nicht visualisiert wird und damit nicht wirklich klar ist, wo die Grenze ist.
die Rechenzeiten auf einem Telephon länger sind und damit ein Herumprobieren, eigentlich aus Zeitgründen flach fällt.
Die Lösung wäre, dass man die NoGo Areas in den AndroidApps visuell wahrnehmbar erstellen könnte. Da man meines Wissen in allen drei AndroidApps Tracks malen kann, könnte man mit denen auch Flächen einmalen. Brouter müsste nur den Anfangspunkt und den Endpunkt verbinden und fertig wäre das Polygon.
Diese Art der Polygone könnte man auch als Go-Areas nutzen.
Wenn meine Sichtweise stimmt, dass man Langstreckentouren eigentlich eher als groben Kanal durch die Landschaft denkt, dann könnte man Via-Punkte auch weich auffassen. Quasi als Gravitationzentren für die Navigation. Ob es jetzt x Meter vorbeigeht ist nicht weiter schlimm.
Jetzt noch Fragen zur Syntax.
switch is_ldcr 1 # always treated as perfect (=1)
add switch stick_to_cycleroutes 0.5 0.05 # everything else somewhat up
Was bedeudet dieses add?
Wenn ein Weg im Verlauf des Parsen eine weitere Bedingung erfüllt, gilt dann die erste oder die letzte Bedingung?
zunächst einmal alle Achtung zum Entwickeln von brouter!
Ich habe jetzt nicht alle etwa 250 Beiträge gelesen. Trotzdem eine Frage.
Ich konnte in den letzten Tagen brouter in Zusammenarbeit mit OsmAnd erfolgreich auf einem Galaxy S4 in Betrieb nehmen. Bei OsmAnd kann ich unter “Einstellungen → Navigation” brouter auswählen.
Nun möchte ich per Fahrrad eine Route erstellen lassen. Das funktioniert auch soweit so schlecht.
EIN Beispiel von vielen:
Im Süden von Berlin – Buckow nach Altglienicke. Dort verläuft der international bekannte Mauerradweg. Auf diesem Streckenabschnitt zum größten Teil auch hervorragend ausgebaut. Auf: http://brouter.de/brouter-web/
mit der Ansicht “Opencyclemap” und “Cycling (Wayemarked Trails)” auch sehr gut zu erkennen.
Wie erreiche ich es, in OsmAnd eine Strecke von Buckow (z.B. Freiertweg) nach Altglienicke (z.B. Lieselstraße) über den (sehr gut!) ausgebauten Mauerradweg zu erhalten und NICHT über z.T. extrem stark befahrenen Straßen. Auch auf brouter.de/brouter-web ist es nur für diejenigen User machbar die die Strecke kennen (über Zwischenziele) oder viel herumprobieren (Menü: Alternative) eine vernünftige Streckenführung zu erhalten. Unterwegs keine Chance. Da muss man dann die vorgeschlagene Route benutzen und an wunderbaren Stellen vorbeiradeln Fremde User/Besucher/Radler würden hier über unmögliche Straßen geführt statt über einen extrem guten Rad (fern-) weg.
Das o.g. war nur ein Beispiel.
Am PC kann man das auf http://brouter.de/brouter-web/ ja noch sehr gut überblicken und selbst für Alternativen sorgen. Unterwegs auf kleinem Display und wenn es schnell gehen soll – keine Chance
Noch schlimmer finde ich ein Routing in der Nähe anderer gut ausgebauter Radfernwegstrecken.
Meine Frage:
Wie kann ich mittels brouter und OsmAnd erreichen, das ich (unterwegs, ohne Internetzugang, eine Route erstellend) möglichst auf vorhanden Radfernwegen geroutet werde (und nicht auf benachbarten, zum Teil stark befahrenen, von Motorlärm dröhnenden) KFZ Straßen?
Welches Profil hast Du verwendet ? Bei fastbike werden vorzugsweise (schnelle) Straßen benutzt, während bei save Straßen nach Möglichkeit vermieden werden. trekking bevorzugt Radrouten, wenn vorhanden. Sind diese richtig getagt ?
Leg doch mal beide Routen in brouter.web an und gib uns jeweils einen Link (Klick auf Permalink und dann URL hier rein kopieren). Dann können wir die “kritischen” Stellen mal in OSM anschauen.
Hallo Peter,
vielen Dank für die Begrüßung und die Antwort.
Ich musste zunächst einmal eine geraume Zeit nach “permalink” suchen
safety benutzt hier ein Gewirr aus Nebenstraßen durch Rudow. Dieser Weg ist nur scheinbar(!) kürzer – schon garnicht besser – als der MauerRadweg. Nein, der wird definitiv auch länger und lange nicht so schön wie der “vorgegebene” Mauerradweg.
“tracking” benutzt einen unmöglichen(!) Weg quer durch – NICHTs für Radreisende oder Radtouren.
liegerad… bzw. vm… routing ist eh völlig daneben und absurd. Die (vor allem velomobilrouting) sehen sich allem Anschein nach lieber zwischen KFZ Schlangen/Staus statt auf breiten und gut ausgebauten UND ruhig gelegenen Wegen UND auch sehr schnell zu fahrenden Wegen. Das nur nebenher.
OK, man/frau sollten eh immer Kartenmaterial mitführen. Nur hier an der Stelle wird mit brouter und OsmAnd etwas angeboten, was (für Radtouren und Reiseradtouren) verbesserungswürdig ist.
Wie schon geschrieben. Wie kann ich oder auch Gäste direkt auf einem Rad(fern-)weg geroutet werden?
Also mir ist das Trecking schon zu radroutenlastig. Aber das ist nicht der Punkt.
Du musst verstehen wie Routing funktioniert.
Nehmen wir Du sagst dem Router, dir sind zwei Kilometer Radrelation lieber als 1 km Bundesstraße. Jetzt gibt es eine Situation, in der du mit 2,01km 1km Bundesstraße umfahren würdest. Schwubs lenkt dich das Routing auf die Bundesstraße.
Das Routing kennt nicht die Gegebenheit vor Ort. Es kennt nur Straßentypen. Lichtenrader Chausee ist eine Tertiary. In meinem Ballungsgebieten die Hölle, 40 Kilometer weiter im Mittelgebierge eine Wohltat. Ein Routing versucht das durch bestimmte Werte unter einen Hut zu bringen.
Ich mache dieses Jahr eine Radtour durch D. Aus meinen bisherigen Erfahrungen habe ich mir mehrere Routenprofile gebaut, um mit regionalen Eigenheit umzugehen. Im Mittelgebierge sind tracktype=grade2 wesentlich rütteliger als in meinem Ballungsgebiet. Dort sind es super Wege. Aber es geht nur um die Befahrbarkeit. Wo es schön ist, muss ich rausfinden.
Wer schön von A nach B kommen will, muss planen. Wer nur von A nach B will, kann beeinflussen, was ihn wie viel ärgern darf.
Fremde User/Besucher/Radler würden hier über unmögliche Straßen geführt statt über einen extrem guten Rad (fern-) weg.