Das Ganze läuft auf die gleiche Fragenklasse wie: Wann ist ein Radweg sinnvoll nutzbar?
Solche hochgradig subjektiven (=nicht überprüfbaren) Informationen in die Datenbank zu schreiben, wurde schon mehrfach abgelehnt.
Diese Informationen sollte man besser in einem eigenen Datensatz verwalten und nur als Overlay über die Karte legen.
Was das Emergency-Routing angeht, kann man zwar versuchen einige Straßenabschnitte beim Routing mit massiven Malus zu versehen, weil sie notorisch verstopft sind. Aber das ist dann wieder auch abhängig von der Tageszeit. (In einigen Vierteln von Köln müsste man bei einem Einsatz eigentlich erst mal eine Flotte von Gabelstaplern vorausschicken um die Falschparker zügig beiseite zu räumen.)
Man kann versuchen anhand bekannter Informationen wie Breite (Welche Breite hat der Eintragende gemeint?), Anzahl der Spuren (Wieviele sind davon zugeparkt?), maxweight, maxlength, hgv=no usw. einige Straßen beim Routing zu benachteiligen. Aber irgendwann gibt es dann Gebiete, die man per Emergency-Routing nicht mehr erreichen kann. Das lokale Wissen der handelnden Personen kann man eben nicht so einfach ersetzen.
Wenn man wirklich etwas erreichen will (und nicht nur an den Symptome herumdoktern will), dann muss man den Verkehrsrechnern beibringen, den Einsatzkräften bei Bedarf freie Fahrt zu schalten.
Nun ja, Glattheit kann man in gewisser Weise überprüfen. Größe, Tiefe und Anzahl der Löcher kann man, so man sich die Arbeit machen will, schon objektiv messen. Wer daraus einen Wert für das OSM-Tagg smoothness ableiten will, lässt natürlich ungewollt/unbewusst (oder nicht) seine subjektiven Gewichtungen und spezifischen Wünschen als xxx mit einfließen.
Was für den Mountainbiker mit seinen “Dicken Reifen” viel zu glatt ist, kann für einen Inliner schon als kaum passierbar gelten. Eher wegen der nach meiner Meinung verkorksten Werte lasse grundsätzlich die Finger von diesem Tagg.
Ist ja alles schön und gut dass man für spezielle Anwendungen auch bestimmte Tags auswerten kann … ABER:
bevor man sowas in der Praxis wie Feuerwehr oder andere Rettungsdienste ausprobieren möchte, sollte man sich auch im klaren darüber werden, wie vollständig solche speziellen Tags wie width=xxx in den OSM-Daten überhaupt vorhanden sind.
Ich würde da mal eine graphische Visualisierung mittels http://overpass-turbo.eu probieren … da mal testen auf alle highways mit einem Parameter width oder ähnlich.
In meinem Freundeskreis sind ein paar Einsatzfahrer (sowohl Rettung als auch Feuerwehr, ist ja in Ö getrennt). Habe jetzt 3 gefragt, welche Kriterien sie anlegen würden und ich habe immer als Antwort bekommen: In eine Einbahn die er nicht kennt, fährt er nicht gegen die Richtung ein.
Damit hast du unzweifelhaft Recht. Das schöne an OSM ist jedoch, dass man selber solche Informationen gezielt eintragen kann, wenn sie einen interessieren. Nach einer gewissen Zeit, sind dann alle Objekte im relevanten Gebiet mit dieser Information versehen. Das ist ja bei Hydranten oder Trockenleitungen nicht anders.
Wir waren ja auch mal bei unserer Feuerwehr, wobei die etwas besser ausgestattet ist: http://wiki.openstreetmap.org/wiki/OSM_besucht_Feuerwehr
Deren Meinung zu automatisierten Routing war eher nicht so gut. Sie meinten vieles sei auch einfach Erfahrungswerte wo man wie schnell lang fahren kann und wie Stauaufkommen ist.
Nichts desto trotz, vielleicht kann man mit Navit da ein wenig experimentieren, denn dort kann man viel justieren.
Es gibt doch hier von einem User eine Karte die speziell für LKW Routing gebaut worden ist. Komm grad nicht auf den Namen. Dort sind ja Gewichte Längen und Höhen der Fahrzeuge berücksichtigt.
Aber eventuell kann man sich dort anregungen holen um die Sache dahin gehend zu erweitern das es dann für Rettungsfahrzeuge passt
Ich bin jetzt erstmal dabei für alle Einbahnstraßen im Ort die Breite und die anzahlt der Spuren anzugeben, ebenso gebe ich die Breite bei allen schmalen straßen, und bei zufahrtswegen an. Ist es möglich bei einer spur anzugeben ob diese häufig beparkt wird?
Und dann ist mir noch aufgefallen das hier viele Feuerwehrzufahrten (also solche die ein entsprechendes Schild haben) als highway=footway gemappt sind.
Und für Staus hoffe ich das da irgendwann eine Vernünftige anbindung an Stauinfos wie z.b. TMC gegeben ist
Das ist in meine Augen der richtige Ansatz: Alles was man braucht mit Standard-Taggs erst mal erfassen.
Bei Straßen, bei denen eine Spur meist zugeparkt ist, tue ich mich auch schwer, ob ich lanes=1 oder lanes=2 eintragen soll. Meist erfasse ich dann keine Spurzahl. Es gibt Key:parking:lane um die (erlaubten) Parkmöglichkeiten auf einer Straße zu beschreiben. Vielleicht hilft das ein wenig weiter. Denn wo man parken darf, wird das in der Regel auch genutzt.
Ob die parking:lane in der Spurzahl enthalten sein soll oder ob sie zusätzlich zählt, ist mir in diesem Zusammenhang leider auch nicht bekannt.
Was trägst du als Breite ein, die Fahrbahn oder die Straße inklusive Gehwege? Da das für mich nicht klar ist (es gibt wohl auch keine überwiegende Meinung dazu), erfasse ich width eigentlich nur bei Straßen ohne Gehweg.
Feuerwehrzufahrten werden oft regulär für andere Dinge wie z.B. Fußwege genutzt. Wichtig sind dabei zwei Punkte: 1) Man darf dort nicht parken und damit den Rettungsweg blockieren. 2) Man sollte die Oberfläche (z.B. grass_paver) erfassen, um einen groben Eindruck über die mögliche Befahrbarkeit mit verschiedenem Gerät zu haben.
Edit: Die Karte OSM Truck QA Map könnte für dich interessant sein. Da kann man viele Einträge darstellen, die für LKW wichtig sind.
lanes gibt an, wie viele Spuren vorhanden sind und trifft keine Aussage darüber, wie diese genutzt wird. Wenn das Parken auf der Straße nicht verboten ist und man den Verkehr nicht behindert darf man seiner Karre dort auch eine Pause gönnen. Sprich man muss auf jeder Straße damit rechnen, dass eine Spur zugeparkt sein kann. Ob das nun häufig der Fall ist oder nicht ist doch unerheblich. Interessant ist es für dich doch nur ob zum Zeitpunkt des Einsatzes dort geparkt wird und das wird man in OSM nicht modellieren können.
Also ich trage immer die Straßenbreite ein die von Fahrzeugen genutzt werden kann. Also in der Regel von Kantstein zu Kantstein, oder wenn keiner da ist von Weißer Linie zu Weiße Linie. Bei fußwegen bin ich eher ein Fan davon diese seperat zu mappen, dann passt das auch bei Fußgängerüberwegen besser.
Aus den Feuerwehrzufahrten die bisher als Fußweg da waren habe ich nun das gemacht
Es kommt natürlich darauf an, ob an dem Weg ein blaues Fußgängerschild steht oder nicht. Ohne ist das schon OK, mit Schild wäre es highway=footway + foot=designated, (motor_)vehicle=no, emergency=yes. Gegebenenfalls können auch Radfahrer erlaubt sein (bicycle=yes/designated).
Es gibt natürlich auch ‘normale’ Wege, z.B. als Zufahrt zu Parkplätzen, die gleichzeitig als Feuerwehrzufahrt genutzt werden. Da wäre dann service=parking_aisle/driveway und (motor_)vehicle=private/permissive angemessener. Dieser Weg ist z.B. sowohl eine private Zufahrt zur rückwärtigen Mitarbeiter-Tiefgaragen, als auch ein öffentlicher Rad-/Fußweg und gleichzeitig eine Feuerwehrzufahrt (kann man an maxweight=20 erkennen). Upps, da fehlen ja das emergency=yes und die Breite.
Mir ging es um das ganz normale parken auf einer Fahrbahn, die keine sonstigen Einrichtungen zum parken bietet. Bspw. Gehsteig|Spur|Spur|Gehsteig
Wenn da jetzt eine Spur zugeparkt ist, bleibt lanes trotzdem 2 und width ergibt sich auch aus der Breite beider Spuren.
Klar ist, wenn auf dem Straßenbelag Parkplätze kenntlich gemacht wurden, dass dieser Bereich dann keine Fahrspur mehr ist und mit parkenden/haltenden Fahrzeugen würde ich immer rechnen, solange es nicht ausdrücklich verboten ist (und selbst da kennen so manche Zeitgenossen keine Hemmungen).
Ich denke das Navigationssysteme im allgemeinen einen Vorteil aus den Erfahrungen der Ortskundigen fahrer ziehen könnte. Ich kann zum Beispiel sagen das ich in den letzen 20 Jahren in einer bestimmten Straße noch nie gesehen habe das da kein Auto parkt. Und die Straße ist nur 100m lang. Außerdem weis ich das an einer bestimmten Kreuzung immer Stau ist (Mit Ausnahme Sonntag morgen 4 Uhr). Solche informationen können für die Routenberechnung genauso hilfreich sein wie Tempolimits. Die Frage die sich mir nur stellt, wie könnte man sowas halbwegs einheitlich angeben. Bezüglich Stau ist Google Vorbildlich, da kommt das klassische TMC nicht nach. Aber Ampelzyklin und ähnliches fehlt auch da noch.
Um alles einheitlich unter einen Hut zu bringen könnte vielleicht etwas in Richtung durchschnitstempo helfen.
Ja, das kannst du sagen und es wird mit sehr hoher Wahrscheinlichkeit dann wohl auch so sein. Aber das hilft dir nicht sehr viel.
Nehmen wir mal einen recht simplen Fall. Die Punkte A (Start) und B (Ziel) sind über zwei Straßen verbunden. Von der kurzen weißt du, dass die immer zugeparkt ist, bei der längeren weißt du, dass sie typischerweise frei sein sollte.
A--------
| |
| |
| |
| |
| |
B--------
Du routest also immer über die längere Strecke. Es kann aber immer vorkommen, dass auch dort mal ein Auto parkt und dann die Straße auch ein Nadelöhr ist. Die Gegeninformation (sollte frei sein) ist eben sehr wage. Weil es braucht nur ein Auto, dass da für eine kurze Zeit parkt und schon hast du da das gleiche Hindernis. Ebenso würde ich mal davon ausgehen, dass eine dann einspurige Straße kein Nachteil ist, wenn ohnehin nicht mit Gegenverkehr zu rechnen ist.
