Changeset: 67127487
Geometrie Hüttentalstr. und AB-Zubringer überarbeitet
Closed by kreuzschnabel
Tags
created_by | JOSM/1.5 (14760 de) |
---|---|
source | Esri World Imagery; survey |
Discussion
-
Comment from Jake Smarter
@kreuzschnabel Bitte mache keine Änderungen an Hauptstraßen, wenn du nicht weist was du tust. Die von dir eingeführte Geometrieänderung existiert in der Realität nicht, außerdem hast du Abbiegebeschränkungen, Routen, Ziele und Spuren nicht beachtet. Nur weil man viele Edits gemacht hat, heißt es nicht, dass man etwas richtig macht. Bitte in Zukunft mehr Vorsicht walten lassen, ansonsten bei Unwissenheit die Finger davon lassen.
-
Comment from kreuzschnabel
Sorry, aber damit ich was dazulerne, könntest du mir etwas genauer sagen, was an meiner Arbeit nicht stimmt? Ich bin am 11.2. mehrfach da langgefahren, wobei mir das ziemlich grobe Mapping der Hüttentalstraße und des Zubringers auffiel. Anhand meiner GPXe habe ich das dann überarbeitet.
-
Comment from kreuzschnabel
Der Rechtsabbiegewinkel von https://www.openstreetmap.org/way/160279380 auf https://www.openstreetmap.org/way/160279385 beträgt jetzt etwa 125 Grad. Entspricht das der Realität? Bei Abbiegewinkeln deutlich über 90 Grad sagen Router im LKW-Modus ganz schnell „da kommen wir nicht rum, nehmen wir lieber einen Umweg“. Deshalb gilt in OSM die Konvention, dass Einmündungen, die nicht real spitzwinklig sind, mit einem Winkel von etwa 90° abgebildet werden. Die Alternative zu der von mir gewählten Möglichkeit wäre hier, auf die Aufteilung ganz zu verzichten und die Verkehrsinsel als traffic_calming=island an den Way zu taggen.
-
Comment from kreuzschnabel
Ergänzung: Praxisfragen des Kreuzungs-Mappens und insbesondere des Hinter-Verkehrsinsel-auf-einen-Punkt-Zusammenführens wurden hier mal ausgiebig diskutiert: https://forum.openstreetmap.org/viewtopic.php?id=54616
-
Comment from Jake Smarter
Wie Navigationsanwendungen OSM-Daten interpretieren ist deren Implementation überlassen. Wenn sie mit falschen oder naiven Annahmen für bestimmte Zwecke hantieren, dann bedeutet das nicht, dass es ein Problem mit den OSM-Daten gibt. Hier gilt analog das Prinzip „Nicht für den Renderer kartographieren“. Die Realität ist zu erfassen und in Daten abzubilden. Linien mit highway=* bilden lediglich die Straßen- und Wegverläufe ab, wobei bauliche Trennungen zu beachten sind. Wenn man die tatsächlichen Fahrbahnen bzw. Fahrflächen erfassen will, dann gibt es dafür auch ein entsprechendes Schema bzw. Vorschläge dafür. Dann kann ein Verwender gerne Annahmen über Winkel im Fahrbahnraum daraus machen.
Für deinen Zweck, d.h. LKWs und über 90° Kurven könnte man die Stelle auch anders /legitim/ Abbilden, obwohl wie gesagt, das ein absoluter Spezialfall und tatsächlich eine naive — wenn nicht sogar eine dumme — Annahme ist: Der durch die Verkehrsinsel aufgespaltene Zubringer könnte auch durch die highway=primary und highway=secondary laufen. Dann hätte man überall 90° Winkel und die naive LKW-Navigation wäre auch wieder happy. Allerdings, würde das eine bauliche Trennung abbilden die nicht existiert. Naja, falsch wäre diese Datenabbildung nicht, aber ob sie an dieser Stelle wirklich hilfreich ist, ist zu bezweifeln. Ich denke, es wäre besser die Navi-Entwickler auf diesen Fall und ihre Annahmen hinzuweisen.
Eine Verkehrsinsel ist grundsätzlich keine Verkehrsberuhigung. Sie kann eine Verkehrsberuhigung sein, ist es aber in der Regel nicht, so wie an dieser Stelle. Verkehrsinseln dienen grundsätzlich vornehmlich der Ordnung des Verkehrsflusses und sind in OSM in der Regel als bauliche Trennung zu behandeln/kartographieren. Sie dienen auch der Sicherheit, aber nur nachrangig. Verkehrsinseln, die als Verkehrsberuhigung ausgelegt sind dienen wiederum vorrangig der Sicherheit und nur nachrangig der Ordnung des Verkehrsflusses.
Abschließend sei noch einmal dringlichst darauf hingewiesen, tunlichst von Edits abzulassen, die zustande kommen „weil mein Navi dabei spinnt“. Ja, dann spinnt es eben, weil in ihm falsche Annahmen gemacht wurden. Daten können falsch sein, aber bitte zuerst die Navi-Entwickler nerven und erst dann die Daten untersuchen (aber nicht zwingend ändern).
-
Comment from Jake Smarter
Lass mich bitte etwas darüber nachdenken, ob wir diese Stelle auf die 90° Winkelvariante ändern, weil sie eben auch akzeptabel ist. Danke!
-
Comment from kreuzschnabel
Ich wäre dir sehr dankbar, wenn du deinen Tonfall um einige Grade versachlichen könntest. Nach einigen Jahren exzessiven Lane- und Destination-Taggings glaube ich auch nicht, dass ich diese Merkmale vollkommen vernachlässige.
Ich habe eine unvollkommene Darstellung der Kreuzung durch eine andere unvollkommene ersetzt, deren Nachteile ich (immer noch) wesentlich kleiner finde, und du hast jetzt wieder eine (noch schrägere) unvollkommene eingesetzt. Mit Unvollkommenheiten müssen wir in OSM leben, solange wir breite Verkehrsflächen, auf denen man sowohl einen weiten Linksbogen als auch einen weiten Rechtsbogen fahren kann, als Linien abbilden, die diese Breite einfach nicht haben. Wir können nur abwägen, welche Unvollkommenheiten bedeutend und welche unbedeutend sind.
Auch habe ich – entgegen deiner Unterstellung – diesen Edit mitnichten deshalb vorgenommen, weil mein Navi spinnt – das tut es nicht –, sondern weil mir bekannt ist, dass in anderen Fällen bereits überscharfe Abbiegewinkel zu Fehlroutings geführt haben, und weil ich der Meinung bin, dass meine Version die Geometrie /sämtlicher/ Abbiegevorgänge (geh sie mal nacheinander durch) realistischer abbildet als die Vorversion oder deine es tun, nämlich ohne überscharfe Knicke und Zickzack-Führungen – zugegebenermaßen um den Preis zweier „virtueller“ Fahrwege innerhalb der Kreuzungsfläche, wo keine bauliche Trennung ist. Tatsächlich hat im Kreuzungsbereich selbst auch die L 531 keine bauliche Trennung, auch der Quersteg ist daher strenggenommen falsch, streng nach Lehrbuch müssten die Zweige der L 531 für die Kreuzung vereinigt werden, aber das würde – da sind wir uns wohl einig – dem Geradeausfahrer einen Zickzackway präsentieren, der mit dem OSM-Grundsatz „keep straight roads straight“ nichts mehr zu tun hätte.
Wenn du deine Version besser findest, bitte, dann lassen wir sie drin, du fährst da wahrscheinlich öfter drüber als ich und sollst keine Magengeschwüre bekommen :) -
Comment from kreuzschnabel
Hier nochmal zum direkten Vergleich: https://ibb.co/jDm29t6
- Wallhausenstraße (669934114), v1
- B 62 (669934115), v1
- B 62 (669934116), v1
- B 62 (8496081), v41
- B 62 (27456889), v26
- B 62 (28119706), v12
- B 62 (28119714), v13
- Wallhausenstraße (28119746), v14
- Wallhausenstraße (28120034), v15
- 28120079, v14
- B 62 (28120099), v18
- B 62 (28120111), v18
- B 62 (28120121), v15
- B 62 (28120127), v13
- B 62 (28120221), v22
- B 62 (29111088), v13
- B 62 (30412965), v16
- B 62 (30412966), v14
- B 62 (32452533), v13
- B 62 (32453045), v18
Relations (6)
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |