Feuerwachen haben oft einen recht großen Hof, über den die Fahrzeuge von den Hallentoren zur öffentlichen Straße fahren.
Ich habe diese Fläche als highway=serviceservice=drivewayarea=yes gemappt. Dabei habe ich driveway und öffentliche Straße verklebt, um die Konnektivität abzubilden. Ist das in Ordnung so?
Oft sind die Tore, wenn sie gemappt sind, nicht mit einem highway verbunden, siehe postpass.
Auf welche Straße von welchem Tor aus gefahren werden kann, ist in komplexeren Fällen nicht rein durch räumliche Nähe eindeutig.
Das Problem ist grundsätzlich das des “Wie routet man über Flächen”. Nachdem wir zwischen abstrakten Straßenlinien und richtigen Straßenflächen unterscheiden (können), hat man das Problem, dass das nicht wirklich miteinander kompatibel ist. Technisch ist es jedenfalls aus beiden Betrachtungsweisen falsch, wenn die Fläche direkt bis zur Mittellinie der angrenzenden Straßen geht.
Inhaltlich frage ich mich aber auch, wem diese “Konnektivität” denn im echten Leben dienen könnte. Mehrere einzelne “zum Tor-Wege” wäre auch unerwünschtes “Spurmapping”. 'Gab letzend hier eine Diskussion zu einem ähnlichen Fall zu einer Vorfläche eines Garagenhofs. (FInde ich gerade nicht)
Ähnliche Fragestellungen findet man in endlosen Diskussionen über Hilfswege in Fußgängerzonen oder die Verbindungen von Gehsteigen mit der Straße.
Im echten Leben dienen würde das vor allem den Feuerwehren und dem Rettungsdienst.
Zum Beispiel hier müsste die Routing-Engine sonst raten, ob das Fahrzeug nach Osten oder nach Westen ausfahren kann, und sich dabei vslt für die nähere Straße entscheiden, was hier falsch ist. Geht das Navi von der falschen Start-Kante aus, hilft es einem nicht mehr bei der Entscheidung, ob man vom Hof aus nach Links oder nach Rechts auf die Straße abbiegen muss. Bei Wachen wie dieser und dieser ist das die erste, zeitkritischste und folgenschwerste Navigationsentscheidung.
Auch wenn viele osm basierte (Blaulicht-)Routingengines nicht explizit mit area=yes umgehen können, klappt es trotzdem ganz gut, man wird halt außenrum geroutet.
Bei highway=footway gibt es das Konzeptfootway=link um Wege einzutragen, die so nicht vorhanden sind, aber für eine Konnektivität für Router notwendig sind. Das ließe sich natürlich auch auf Zufahrten anwenden. Hat vermutlich den Nachteil, das diverse Renderer die Wege anzeigen, was unschön aussieht. Hat aber auch den Vorteil, dass man die Fläche der Zufahrt korrekt eintragen kann und das Routing “korrekt” ist.
Damit ist das Routing vom Wachentor bis zur nächsten Straße eigentlich ganz akzeptabel gelöst. Im Fall von @dadavid kann man eine Straße auch innerhalb der Rangierfläche ergänzen, die knapp an den Gebäuden vorbeiführt.
Je nach dem wo es hingeht, muss man halt nach Links oder Rechts raus. Wenn das Navi dann mit rerouting beschäftigt ist, wirds doof. Wenden auf Alarmfahrt ist übrigens richtig nervig und ziemlich peinlich.
Maschinist:innen und alle anderen mit Blaulicht-LKW Erfahrung können über den Sinn und Unsinn von Navis gern in einem separaten Thread diskutieren.
Eine Verbindung zwischen Tor und Straße hilft dem Router, die richtige Start-Kante auf der öffentlichen Strasse zu finden. Wenn er raten muss, landet er oft hinterm Haus, und braucht beim Ausrücken Zeit fürs rerouting.
Die richtige Start-Kante zu finden ist wichtig, damit das Fahrzeugnavi zeigen kann, ob man bei unbekannten Einsatzstellen nach Links oder nach Rechts vom Hof auf die Straße abbiegen soll. Außerdem ist die Straße hinterm Haus ggf sehr langsam bzw hat eine Schranke, was die ETE Schätzung vom Einsatzleitsystem verändert, was wiederum zu einer schlechteren Disposition führen kann. Das sind Probleme, die im Alltag von Feuerwehr und Rettungsdienst relevant sind.
Spricht etwas gegen den Ansatz mit einem way highway=serviceservice=drivewayarea=yes, der die entrance=garage nodes beinhaltet und dort auf voller Länge mit der Straße verbunden ist, wo ein Auffahren möglich ist?
Wie anfangs erwähnt: Ja, da es nicht zutrifft, dass die Fläche bis zur Straßenmitte geht. (Das würde für den Autoverkehrsrouter zudem bedeuten, dass er hier zwei aufeinanderliegende Routingwege vorfände.)
Im Grunde ist es für den Router egal, ob die Zufahrt 5 oder 20 Meter breit ist - Dem Router reicht eine Linie vom Hof zur Straße mit einem einzigen Verbindungspunkt. Siehe auch die obige Aussage von @osmmapper222
Besser geeignet ist https://wiki.openstreetmap.org/wiki/DE:Key:area:highway - löst aber das Routing"problem" (derzeit) nicht.
Eine einzige Verbindungskante für den gesamten Hof, zb in der Mitte, führt bei Toren am Rand zu ca 100m unnötig falsch angenommene Fahrtroute. Die Zeit macht beim Einsatzmittelvorschlag durchaus einen Unterschied. Außerdem gibt es diesen Weg in der Realität nicht, das wäre mapping for the router, es sei denn man sieht den Hof als 15m langen und 80m breiten highway=service, ist das wirklich gut?
Und tatsächlich geht der Hof nahtlos bis an die Straße, genau wie der nebenliegende Platz übrigens auch. Nichts hält Fahrzeuge physisch davon ab, auf den Hof zu fahren, außer der gemappten rechtlichen Restriktionen, die Situation on the ground ist also korrekt abgebildet.
Ich weiß nicht was ein Routingweg sein soll, aber welcher Router kann nicht mit übereinanderliegenden Kanten umgehen? Es wird halt die mit dem niedrigeren Gewicht gewählt.
Welches Problem erzeugt area=yes, das area:highway löst?
Danke für deine ausführliche Erklärung und den spannenden Einblick!
Ich sehe was so wie @pyram . Zusätzlich sind die Zufahrten ja eigentlich untergliedert: Zumindest zwischen den ersten und zweiten westlichen Drittel durch eine Kopfsteinpflasterfläche, die laut Luftbild und mapillary als Parkplatz genutzt wird. Zwischen den 2. und 3. Drittel gibt es noch so eine, da ist mir aber nicht klar, ob es eher Fußweg zum Haupteingang oder Parkplatzfläche ist. Der Teil westlich von Gebäude scheint mir eher ein breiter Fußweg zu sein als eine Zufahrt, die irgendwo hin führt. Vielleicht ist der Bereich auch Parkplatz?
Du könntest 3 Einfahrten mit width 15, 20 und 23 Metern einzeichnen (hier lila, ich habe es nur grob gemessen) und dazwischen die Parkplatzflächen. Plus ggf area:highway.
Klasse dass du dich mit der Situation vor Ort beschäftigt hast
Das sind tatsächlich keine Parkflächen sondern normaler Teil Feuerwehrhofs, auf dem geübt und ausgerückt wird. Da sie nicht direkt vor einem Tor liegen, werden sie seltener befahren und sind deswegen nicht asphaltiert. Bei Alarm werden zuerst dort Privat-PKW abgestellt, die später Ankommenden parken dann vor den Toren der bereits ausgerückten Fahrzeuge. Außerhalb vom Einsatz darf dort nicht geparkt werden. Wenn dort noch niemand steht, wird quer über die Fläche ausgerückt. Der westliche, gelb markierte Teil liegt vor der Tankstelle und dem Nebeneingang. Dort wird auch geübt, gefahren, getankt und angeliefert.
Man könnte das natürlich als die drei von dir genannten ways mappen, aber es bildet die Situation vor Ort weniger gut ab. Welches Problem löst man denn dadurch? Das ist mir auch in den verlinkten allgemeinen Diskussionen nicht ganz klar geworden, nur dass da der Vorteil von area=yes auch meist fraglich war.
Der Hof geht natürlich nicht bis zur Straßenmitte, sondern bis Straßenrand. Genau wie einmündende Querstraßen auch, die werden ja auch mit dem way verbunden und enden nicht am Rande der Straßenfläche. Es ist also Konsens, dass der Verlauf des normalen Straßen-Ways die Straßenmitte abbildet und die diversen width:* tags die Straßenbreite, was zusammen seine Geometrie ergibt. Anschlüsse und Einmündungen beziehen sich auf den Rand dieser Fläche.
Ich möchte keine Landuse-Verklebe-Diskussion anfangen, hier geht es um tatsächliche Verbindung und Überfahrbarkeit von highway zu highway. Fraglich ist noch, wie ein separat gemappter Fußweg da reinpassen würde. Da kommt ggf wieder link ins Spiel.
Trotz oder gerade wegen des beschriebenen Routingproblems könnte man doch bis zu einer sinnvollen endgültigen Lösung bei solchen Vorplätzen von Feuerwachen ähnlich vorgehen wie es bei Fußgängerzonen Usus ist (z.B. München)?
Also einmal die Fläche als highway=serviceservice=drivewayarea=yes und dann noch zusätzlich Verbindungswege zu den Toren oder zumindest einen “Rundweg” der knapp an der Gebäudekante vorbei führt.
Das ist so nicht in Ordnung, da wir bei OSM Flächen nicht an Linien “kleben”.
Korrekt wäre in diesem Fall die Fläche genau dort einzuzeichnen wo sie ist, nämlich von Feuerwehrgebäude bis zum Rand des Gehweges.
Die Attribuierung dieser Fläche hast Du hier bereits vollkommen korrekt gemacht.
Wenn sich Fläche und Gebäude eine gemeinsame Kante teilen und die Tore auf dieser Kante gemappt sind, dann sind sie auch Teil eines highway.
Da die Feuerwehr immer auf die gerade vor Ihrem Tor liegende Straße fährt ist das vollkommen eindeutig. Leider kenne ich bisher keinen Router der diese für den Menschen einfache Variante auch so umsetzt. Hier müssen wir wohl noch ein wenig warten.
Um den bestehenden Routern das Leben ein wenig einfacher zu machen können wir entsprechende Wege von der Fläche zur Straße definieren. Diese würde ich tatsächlich ähnlich anlegen wie das schon beschireben wurde: Hof einer Feuerwache: Wie Tore mit Straße verbinden? - #13 by Metzor
Das dann der Router womöglich immer noch den ein oder anderen Umweg nimmt ist nicht mehr das Problem der Daten sondern des Routers. Für das Einsatzleitsystem kann das auch heißen, dass der Startpunkt der Route nicht in der Garage sondern auf der davorliegenden Straße ist, die zusätzlichen 10 m Hof fallen da nicht ins Gewicht.
Völlig richtig. Das trifft aber nicht auf als Flächen gemappte “Straßen/Plätze” zu. Bei Flächen ist es üblich sie genau so einzuzeichnen, wie sie sind. Sprich wenn die Straße nur als Linie eingetragen ist und der Hof als Fläche ergibt sich zwangsweise eine Lücke, die man dann mit einem kurzen Linien-highway=service überbrücken muss.
Man könnte auch umgekehrt argumentieren: Es sind Parkflächen, die - wenn sie leer sind - auch befahren und zum Üben genutzt werden können. Wenn es separat eingetragen ist, könnte man auch die unterschiedlichen surface eintragen.
Bildet es sie wirklich schlechter ab? Hinsichtlich Routing halte ich die 3 Wege für besser als auf dem Rand der highway-Fläche innerhalb der Gebäude-Mauer unrealistisch um die Ecken zu fahren. 3 Wege ist eine Abstraktion vom (ungewünschten) Spurmapping. Dennoch müssten die 3 Wege meiner Meinung nach sicherstellen, dass von jedem Garagentor der Router einen der drei Wege als nähste routbare Kante erkennt statt auf etwaige Wege auf der Rückseite der Fahrzeughalle.
Wenn du zusätzlich zu den 3 Wegen eine highway=service mit area=yes einzeichnest, die sich an die Gebäudekante anschließt und wie oben geschrieben an der Kante vom Gehweg endet, würde es eben ein paar Meter in der Gebäudemauer entlangrouten, dann von einem der 3 Wege direkt auf die große Straße.
