Diese TR sind sowieso vollkommen unnötig und können m.E. auch so weggelassen werden, ohne getrennte Fahrbahnen zu mappen. Um die Verkehrsinsel herum im extrem spitzen Winkel abbiegen (faktisch wenden) sollte kein Router machen. Solche Umwege werden von vornherein nicht geroutet. Und wenn man falsch abgebogen ist - bis das Navi das merkt und neu berechnet hat, ist man praktisch an dieser Stelle längst vorbei gefahren. Dass man praktisch nur geradeaus fahren kann ergibt sich ja aus den Geometrien und den oneway - mehr braucht es da nicht!
Ich würde hier die ways ebenfalls schlicht im rechten Winkel anordnen. Gut, bei I könnte man wegen dem Feldweg vielleicht streiten.
Das Rechtsabbiegeverbot in I ist falsch, wenn überhaupt notwendig, dann ist das hier ein Geradeaus-Gebot (nach Fahrbahnmarkierung).
Bin ich vollkommen bei dir. Teilweise geht da ja auch schon was - Aber routing ist bei OSM seit langem halt nur so ein “2nd class citizen” - Ja das geht auch - defakto guckt sich das strategisch kaum einer an. Das ist zumindest mein Empfinden nach 10+ Jahren QA im Routing.
Es gibt keine saubere doku welche tags von welcher engine/profile wirklich supported werden etc. Jede macht das so ein bisschen anders und alles was kompliziert wird ist eh kaputt oder nicht supportet. Dafür ist das ergebnis ganz passabel - Aber *=destination ist so mein Liebling - der ist überall kaputt.
Mein aktuelles thema ist eher “traffic_signals” die mit direction nicht sauber gehen und dann kreuzungen häufig doppelt und dreifache penalty bekommen. Aber ja - ist ein routing engine thema.
Damit einher geht auch irgendeine software die auf jedem highway=crossing/crossing=traffic_signals ein highway=traffic_signals ersetzt. Ist halt nicht dasselbe und letzteres gibt halt viel mehr Penalty. Macht halt das routing kaputt.
Und ganz ehrlich. Für die Emergency services müssen wir echt wenig taggen. Die sind JEDEN TAG da draussen unterwegs. Die kennen auf den Auf und Abfahrten jeden Kieselstein.
Ich weiss das die Leitstelle in GT OSM aktiv nutzt und sogar selber dinge korrigiert. Deren Problem sind aber so wie ich das sehe eher Fehler in der benennung von Straßen, gerne genommen alle service/driveways mit namen taggen (auch falsche) so das Kreuzungen von Straßen entstehen die in wirklichkeit keine Kreuzungen haben. Service road über den Hof geht bis zur anderen Seite - name drauf - Zack neue Kreuzung zweier angeblich benannter Straßen die aber gar keine Kreuzung haben.
Wenn dann noch ein Notruf kommt der 2 Straßen benennt fährt der RTW an die falsche stelle - Hier in GT mehr als einmal passiert. Deshalb hatte ich mit denen Kontakt weil da Minutenlang gesucht werden musste.
Tatsächlich hat mich MagicEarth jetzt schon mehrere Male korrekt zu Orten mit access=destination geführt. Es wird dann auch extra darauf hingewiesen, dass das ZIel in einem Anlieger-Frei-Bereich liegt. Ob das einfach nur die Ansage zur Folge hat und sonst wie yes gewertet wird, weiß ich nicht, die Routing-Engine ist ja vernutlich nicht OpenSource.
Absolute Zustimmung. Vielleicht wäre es mal Zeit einen „Routing-Gipfel“ oder ein Sub-Projekt ins Leben zu rufen, welches die nötigen Kontakte hält und immer auch ggf. Rückmeldung einholt, was gut geht, schlecht geht, gar nicht geht und entsprechend Empfehlungen ausarbeitet, welche Tags grundsätzlich berücksichtigt werden müssen, um z.B. als „offiziell abgenommen“ zu gelten. Nicht genau so, aber in etwa. Ich finde es nämlich frustrierend, dass wir tags wie change:* haben, die dazu gedacht sind, Spurwechsel und damit verbundenes Abbiegen zu verbieten, die dann aber auch noch empfehlen, TRs zu setzen, weil sonst das Routing kaputt ist. Das macht sich damit ja irgendwie selbst überflüssig. Und solange das so ist, wird da auch kaum Verbesserung kommen.
Das Problem ist viel komplexer als das - Das problem ist das mit A* oder Dijkstra du alle Probleme zu “Kostenproblemen” machen musst. D.h. die standard Algorithmen machen aus einem “access=destination” ein Kostenproblem je Meter. Und das ist falsch. Denn du hast nur “einmalkosten” wenn du in den gesamtbereich des access=destination einfährst und nicht distanzabhängige kosten.
D.h. diese teilbereiche dürfen nur eingefahren werden wenn dort das ziel oder der startpunkt liegt. Das ist stand heute mit keinem Router/Navigator der Fall. Wenn du die kosten drumherum nur groß genug machst schickt dich jeder router da durch.
In den allermeisten fällen fällt das nicht auf weil die Bereiche relativ klein sind, wenn du aber im Aussenbereich gerade Straßen hast die Kilometerlang sind und motor_vehicle=destination, versuchen alle router/navigatoren dich “schnellstmöglich” da runter zu bringen was aber quatsch ist. Das liegt aber eben an dem “Kostenproblem”.
Kosten je Meter auf öffentlichen Straßen 1€
Kosten je Meter auf destination 2€
Frauke, ich mappe genauso wie Du… eine einfach oder zweifach durchgezogene Linie ist für mich keine bauliche Trennung und ich hätte die Zufahrten genau wie Du in dem Bereich ohne bauliche Trennung zu einer Linie zusammengelegt, so wie hier: Way: 437063201 | OpenStreetMap oder Way: 4226355 | OpenStreetMap
Was Turn-Restrictions betrifft bin ich da auch Deiner Auffassung und sehe darin kein Problem.
Problematischer finde ich, wenn die Definition einer baulichen Trennung der Richtungsfahrbahnen aufgeweicht wird. Es ist klar definiert, dass eine Linie, egal ob einfach oder doppelt durchgezogen, selbst eine Sperrfläche keine bauliche Trennung darstellt. Und wir reden hier nicht von einem Kreuzungsbereich, bei dem man, um einen Zickzackkurs der Straßenlinien zu vermeiden, darauf verzichtet, die Richtungsfahrspurgen für den Kreuzungsbereich zu einer zusammenzulegen.
Problem - Wenn der unterschied der Kosten im Graph zu groß ist wirst du weiträumig um den “*=destination” bereich rum geführt um dann auf dem Kürzesten weg innerhalb des bereiches zu deinem Ziel geführt zu werden.
Gut: Es wird sehr wahrscheinlich gemieden
Schlecht: Es werden umwege für die in dem Bereich liegenden Ziele erzeugt.
Schlecht: Der router hat die bestrebung dich auf dem kürzesten weg raus zu schicken auch wenn das dann viel Umweg bedeuted
Wenn der Unterschied zu klein ist
Gut: Du bekommst sauberes routing für ziele/start innerhalb des Gebietes
Schlecht: Es wird nicht sehr dominant gemieden.
Egal wie du es machst - Es ist IMMER kaputt - Die Frage ist nur für wen. Je nach parametrisierung des A*/Dijkstra bzw des Kostenmodells mal für die die drum müssen oder für die die reinfahren dürfen.
access=destination ist kein distanzabhängiges Kostenmodell.
Nur so mal ein Beispiel - Der Udenbrink ist von vorne bis hinten motor_vehicle=destination
Graphhopper - +900m Schnell von der motor_vehicle=destination runter (Udenbrink)
Noch schlimmer OSRM - 2km Umweg:
Es gibt aber überhaupt keinen Grund das zu machen weil wenn mein Startpunkt darin liegt ist mein Recht diesen Bereich zu befahren gegeben.
Aber das hat mit diesem Thread auch nichts mehr zu tun - Mit fehlern in Routing/Navigation können wir Abende füllen.
Natürlich nicht, aber es ist doch kein Problem des OSM-Datenmodells, wenn Router das so abbilden, sondern ein Problem der Router.
Instruktiv würde ich access=destination beschreiben als “Befahr einen solchen Weg nur dann, wenn das Ziel anders nicht zu erreichen ist” oder auch “… wenn von dem Punkt, wo du access=destination befährst, bis zum Ziel durchgehend access=destination besteht”. Ich kenne mich mit Routerprogrammierung nicht aus und weiß daher nicht, wie leicht das zu implementieren ist. Meine zweite Formulierung ist aber nicht tolerant gegenüber Mappingfehlern (abschnittsweise fehlendes access=destination), daher ist die erste vermutlich besser.
Das Problem ist aber, daß das von der Realität nicht gedeckt ist.
Siehe das Beispiel in meinem Thread. B 19 durchgehend “Kein Durchgangsverkehr ab 12 T”, alle Straßen drumherum ohne Einschränkung.
Da hatte ich auch erst die Idee, ein “Gebiet” zu definieren. Mußte dann aber feststellen, daß nur eine Straße für den Durchfahrtsverkehr gesperrt ist. Die meisten Ziele, die das Befahren der Straße erlauben, liegen nicht an der Straße.
Deshalb ist das für mich eher ein Konflikt zwischen Politik und OSM. Eigentlich will die Politik den Durchgangsverkehr auf der B 19 raushaben, der soll auf die Autobahn. Aber anstatt daß ein Gebiet definiert wird (so daß man sagen könnte: Ziel im Gebiet, erlaubt, Ziel nicht drin, nicht erlaubt), wird nur eine Straße “teilgesperrt”.
Es ist “vage” von einem 75-km-Umkreis die Rede. Die Bürgerinitiative regt sich auf, daß so wenig kontrolliert wird - und stellt selbst fest, daß die Kriterien schwammig seien.
Was politisch schwammig ist, kann nicht präzise im OSM erscheinen.
Also ich selbst würde das so machen, dass ich – wenn das Ziel in destination ist – alle angrenzenden destinations im Preprocessing entfernen und danach einfach wie no behandeln. Viel mehr braucht’s ja nicht.
…und dann ist es noch immer ein Problem des Routers und dessen (mitunter falsch ausgewerteten?) Algorithmen und nicht das von OSM, und hat folglicherweiser hier nichts zu suchen!
"Das Englische original ist hier Sinngemäß anders. Es spricht davon das getrennt gemapped werden kann (should) wo passend (appropriate). "
Deine (und anderer) harte position der trennung nur bei baulichen Trennung ist eine partikularmeinung der Deutschen Community und innerhalb dieser nur wiederum eines teils. Und durch immerwährende Diskussionen in den letzten 15 Jahren ist die ja auch nicht richtiger oder konsensfähiger geworden.
Wenn das Bestand hat müssten alle seperat gemappten Bürgersteige entfernt werden. Dort existiert keine bauliche Trennung (Für die Fußgänger) - nur um mal zu verdeutlichen was deine harte position an konsequenzen hätte.
Ich halte das, wie ich hier ja im Details ausgeführt, für nicht zielführend so zu mappen.
Darüberhinaus gibt genau an der Stelle Auf-/Abfahrten keinen Grund. Jedenfalls habe ich hier ausser das Thema Sonderrechte die potentiell wenden dürften keinen gehört.
Wo wir hier so schön bei geometrieen sind - Kann mir jemand erklären woher die Geometrie dieser Straße kommt? Also der Nördliche teil der einmündenden B55.
Also das Menschen mit dem Auto vielleicht so einen Bogen fahren mag ja sein. Aber wir mappen ja physische Straßen nicht statistische Fahrwege.
Natürlich kommt es hier wieder zu dem “links halten” “rechts halten” wenn man von süden kommt weil für den router das eine “Gabelung” ist. Ich würde den change also tendentiell reverten weil es nichts reales gibt was diese geometrie rechtfertigt, und dazu die Ansagen im Routing kaputt macht.
Östlich ist zwar keine Verkehrsinsel - aber ist die weniger befahrene Straße die dann einen Fehler beinhaltet. Einen Fehler muss man ja machen. Entweder man ignoriert die Verkehrsinsel, man baut kaputte geomtrieen oder man baut ein Dreieck in die weniger genutzte Straße.
Ich finde alle 3 Lösungen okay – alle haben ihre Daseinsberechtigung. Persönlich würde ich wie die letzte mappen. Dass viele Abbiegungen wie “X halten” angesagt werden, ist eigentlich kein Problem, welches ich durch Geometrie lösen würde. Gab dazu mal einen guten Vortrag, wie man Kreuzungen besser zusätzlich als Flächen erfasst, um genau dieses Problem gut lösen zu können.
