Aktuelle Erläuterungen zum Mappen von Kreuzungen?

Zur Lage:
https://www.openstreetmap.org/#map=18/5 … 2&layers=N Grundsätzlich hätte ich es nicht anders erfasst, als man in OSM sehen kann... Bei den oberen beiden Ausschnitten sieht man schön eine Generalisierung, die wir so nicht machen...

Sven

Es ist natürlich nicht verboten, jede Straße lediglich als einen einzelnen Way zu erfassen und Kreuzungen so einfach wie möglich zu halten. Wenn man detaillierter werden will, gelten für mich folgende Grundsätze, deren erste zwei einander schon etwas beißen:

- Eine Straße wird nur dann und möglichst immer dann zu zwei Ways, wenn dazwischen eine bauliche Trennung liegt (Leitplanke, Verkehrsinsel o.ä.).
- Der Straßenverlauf in OSM sollte der realen Fahrlinie in etwa entsprechen.

Satz 2 heißt, dass ein einfach geradeaus fahrendes Fahrzeug in OSM kein Zickzack vorfinden sollte, der entsteht, wenn wirklich sklavisch jede bauliche Trennung, auch eine 2 m lange Insel, zum Aufteilen der Ways führt. Hier gilt es Kompromisse zu finden.

- Alle gemappten Abbiegewinkel sollten der tatsächlichen Kreuzungsgeometrie entsprechen.

Das heißt, dass die Zweige einer in zwei Richtungsways aufgeteilten Einmündung nicht hinter der Insel einfach gemeinsam auf die Zielstraße treffen, denn dort sind dann alle Rechtsabbiegungen zu scharf abgebildet. Kann man problemlos in beide Richtungen abbiegen, sollte ein rechter Winkel gemappt werden. Ich verweise da auf meinen Blogeintrag unter https://www.openstreetmap.org/user/kreu … iary/43843.

- Ist eine Straße vor und hinter der Kreuzung in zwei Richtungs-Ways aufgeteilt, wird die Aufteilung über die Kreuzung beibehalten.

Also nicht erst trennen, dann zusammen, dann trennen, dann wieder zusammen. Das gibt wieder den oben angesprochenen Zickzack.

Soviel von mir auf die Schnelle dazu.

--ks

Noch was: Wenn an Aufteil-Enden nicht gewendet werden darf (das ist meist per durchgezogener Mittellinie verboten), dann muss da ein Wendeverbot gesetzt werden, sonst sind das für umleitungssuchende Router willkommene Wendestellen!

--ks

streckenkundler wrote:

Bei den oberen beiden Ausschnitten sieht man schön eine Generalisierung, die wir so nicht machen...

kreuzschnabel wrote:

Der Straßenverlauf in OSM sollte der realen Fahrlinie in etwa entsprechen.

Bei einem Navi, und auch bei OSM, ist jede Kreuzung in einem Wohngebiet ja meist ein rechter Winkel. Also eine Generalisierung und nicht reale Fahrlinie. (Ja, Strassenverlauf != Kreuzung, aber grundsätzlich ist so eine Karte halt immer viel Generalisierung...)

Bei komplexeren Kreuzungen versuchen Karten(-hersteller) dem Nutzer mehr zu bieten, um zu helfen.

Persönlich finde ich viele OSM-Kreuzungen oft eher verwirrend und herausfordernd. Aus Sicht eines Navi-Nutzers ist die HERE-Version oben z.B. gut. Eine einfach zu fahrende Stelle wird einfach dargestellt. Die OSM-Version lässt einen diese Stelle studieren.

Aber gerade eben weil man bei diesen Dingen so unterschiedler Meinung sein kann, wäre ich halt heilfroh, wenn es dazu irgendeine Quelle gäbe, die offiziellen Charakter hat.

Um nochmal ein konkretes Beispiel zu liefern. Persönlich finde ich Google und Here bei dem folgenden Beispiel auch super. OSM's Daten würde ich ändern. Irgendwer muss einem doch sagen (können), ob ich das nun darf und was OSM's exakte Regeln sind:

Bei OSM gibt es nix offizielles, nur einen Schwarm-Konsens (oder auch nicht 😉 ).

Wie oben bereits gesagt wurde, darf man eine Straße bei baulicher Trennung in 2 OSM-Ways splitten.

Wenn Du gute Gründe hast, die Einmündung zu vereinfachen solltest Du mit dem Ersteller Kontakt aufnehmen und ihn fragen.

chris66 wrote:

... solltest Du mit dem Ersteller Kontakt aufnehmen und ihn fragen.

In der Praxis ist das bei detailverliebten Mappern erfahrungsgemäß nur bedingt hilfreich, da deren Antwort in aller Regel vorhersehbar ist :-(
Hier ist zudem kaum noch herauszufinden, wer das eigentlich so gemacht hat. Scheint schon sehr lange so zu detailiert zu sein.
Auf dem ersten Blick schaut es nach dem user simlox aus, aber der hat das auch nur leicht verschoben: http://nrenner.github.io/achavi/?changeset=54740686
Ich tippe auf einen Umbau vor sieben Jahren:
http://nrenner.github.io/achavi/?changeset=16355826 nebst
http://nrenner.github.io/achavi/?changeset=16356411

Persönlich halte ich vor allem zwei Dinge an dieser Kreuzung für suboptimal:

1. Die scheinbare "Mehrfachkreuzung" in der Mitte ergibt eigenartige Möglickeiten der Verkehrsführung https://www.openstreetmap.org/direction … %2C9.93914
2. Der Weg nach Norden ( https://www.openstreetmap.org/way/42756412 ) ist tertiary
und die Gegenrichtung ( https://www.openstreetmap.org/way/547739751 ) unclassified. Das sollte IMHO nicht unterschiedlich sein.

chris66 wrote:

Bei OSM gibt es nix offizielles...

Wenn sich ein paar von dieser Liste zusammentun und alle bitten einfachste infrastrukturelle Dinge wie Strassen, Kreuzungen, etc. bitte so und so zu mappen, wäre mir das bestimmt offiziell genug.

pyram wrote:

Persönlich halte ich vor allem zwei Dinge an dieser Kreuzung für suboptimal:
1. Die scheinbare "Mehrfachkreuzung" in der Mitte ergibt eigenartige Möglickeiten der Verkehrsführung.
2. Der Weg nach Norden ist tertiary und die Gegenrichtung unclassified. Das sollte IMHO nicht unterschiedlich sein.

Ist so. Deswegen frage ich auch nach Regeln. Irgendjemand wollte etwas "nicht generalisiertes" auf den Weg bringen, und auch Jahre später ist es noch nicht fertig. Allerdings kann man nirgendwo nachschlagen, wie es denn nach der Wartung bitte aussehen soll.

i_am_a_burger wrote:

Wenn sich ein paar von dieser Liste zusammentun und alle bitten einfachste infrastrukturelle Dinge wie Strassen, Kreuzungen, etc. bitte so und so zu mappen, wäre mir das bestimmt offiziell genug.

Mir nicht.
Wie viel % der Mapper (Liste) würde für andere Mapper (nicht auf der Liste) entscheiden (wollen)?

i_am_a_burger wrote:

chris66 wrote:

Bei OSM gibt es nix offizielles...

Wenn sich ein paar von dieser Liste zusammentun und alle bitten einfachste infrastrukturelle Dinge wie Strassen, Kreuzungen, etc. bitte so und so zu mappen, wäre mir das bestimmt offiziell genug.

Ich finde meinen Namen auch auf der Liste, halte mich aber nicht für kompetent genug, ich habe aber mehrere Meinungen zu dem Problem, die Dich wahrscheinlichst nicht weiterbringen werden.
Zielführendste meiner Meinungen: das haben wir hier schon diverse Male ohne Ergebnis durchgekaut, vlt dort nochmal nachlesen?

MKnight wrote:

... das haben wir hier schon diverse Male ohne Ergebnis durchgekaut,

Gibt es einen Ort mit den besten Daten? Wo sich die Mapper anständige, einheitliche Regeln auferlegt haben, die jeder strikt zu befolgen hat? So eine Art "Musterhausen"?

i_am_a_burger wrote:

Gibt es einen Ort mit den besten Daten? Wo sich die Mapper anständige, einheitliche Regeln auferlegt haben, die jeder strikt zu befolgen hat? So eine Art "Musterhausen"?

Nein.

i_am_a_burger wrote:

Gibt es einen Ort mit den besten Daten? Wo sich die Mapper anständige, einheitliche Regeln auferlegt haben, die jeder strikt zu befolgen hat? So eine Art "Musterhausen"?

Überleg noch mal. Kann es in einem offenen Projekt mit ganz vielen Freiwilligen, die sich nicht absprechen, wer was macht, sondern die ohne jede Zuständigkeits-Priorisierung alle kreuz und quer über den ganzen Globus rummappen können und dürfen, wie sie es gerade sinnvoll finden, so einen Ort geben? Selbst wenn jeder nur an seinem Wohnort mappen dürfte (was bis heute eine ziemlich leere Karte zur Folge hätte), wären solche strikten Regeln jedem neu zuziehenden Mapper zunächst mal unbekannt.

--ks

kreuzschnabel wrote:

Kann es in einem offenen Projekt mit ganz vielen Freiwilligen, die sich nicht absprechen, wer was macht, sondern die ohne jede Zuständigkeits-Priorisierung alle kreuz und quer über den ganzen Globus rummappen können und dürfen, wie sie es gerade sinnvoll finden, so einen Ort geben?

Klar könnten sich in einem Ort Mapper absprechen, eine Mehrheit bilden und auf vernünftige Dinge einigen:

- oneway kann nur true sein, alles andere ist falsch oder redundant.
- alle Tempo-30-Zonen sind highway=residential.
- Strassen werden nach hinzufügen von Endpunkten für Rad- bzw. Fusswegen wieder begradigt.
- überflüssige Nodes werden konsequent entfernt.
- Jede Strasse kriegt lanes, maxspeed, surface
- etc. pp.

Musterhausen macht einfach die Dinge einheitlich, die ganz sicher einheitlich gemacht werden können.

kreuzschnabel wrote:

Selbst wenn jeder nur an seinem Wohnort mappen dürfte (was bis heute eine ziemlich leere Karte zur Folge hätte), wären solche strikten Regeln jedem neu zuziehenden Mapper zunächst mal unbekannt.

In Musterhausen wäre ich gerne der zuziehende Mapper.

i_am_a_burger wrote:

Persönlich finde ich viele OSM-Kreuzungen oft eher verwirrend und herausfordernd.
...
Persönlich finde ich Google und Here bei dem folgenden Beispiel auch super. OSM's Daten würde ich ändern.
https://i.imgur.com/i0eRFVh.png

Aber bitte nicht einfach anpassen, nur damit es unter osm.org schöner aussieht. OSM ist eben eine Datenbank, die meist/möglicherweise mehr Daten beinhaltet als Google-Maps oder HERE.
Das Darstellen obliegt dem Renderer!

VG Uwe

uvi wrote:

Aber bitte nicht einfach anpassen, nur damit es unter osm.org schöner aussieht.

+1. Das Rendering auf osm.org ist nur ein Beispiel und keinesfalls eine Referenz für Schönheit oder Richtigkeit.

@Ausgangsfrage: Wenn die Datenlage in OSM faktisch falsch ist, darfst und sollst du sie natürlich ändern. Davon lebt das Projekt. Aber eine detailliert erfasste Kreuzung re-generalisieren, nur weil du persönlich nicht so detailliert arbeitest oder darin keinen Sinn siehst, das wäre für mich eindeutig an der Grenze zum Vandalismus (Grenze deshalb, weil ja kein destruktiver Schaden an der Nutzbarkeit angerichtet wird, lediglich die Arbeit anderer wird weggeschmissen).

Jeder mappt so, wie er/sie es für sinnvoll hält und wie es optimal an die Arbeit anderer Kollegen in der Umgebung anschließt. Wie detailliert eine Kreuzung in OSM abgebildet wird, ist Geschmackssache, und das wollen wir sogar so, solange die Daten nicht falsch sind (d.h. solange sie die reale Situation so abbilden, wie es den im Wiki festgelegten Vereinbarungen oder auch der normativen Kraft des Faktischen entspricht, so dass in allen denkbaren Auswertern ein ordentliches Ergebnis rauskommt).

Wenn du Homogenität im Datenbestand suchst, bist du nicht nur bei OSM falsch, sondern generell bei Community-Projekten. Guck mal nebenan nach Wikipedia. Dort gibt es zwar Richtlinien, wie z.B. ein Artikel über eine Kleinstadt aufgebaut sein sollte, aber das sind keine starren Regeln; wenn du dort eine Kleinstadt reinstellst, kannst du den Artikel zurechtzimmern, wie du willst (andere werden ihn dann möglicherweise umzimmern, genau wie in OSM Kreuzungen umgebaut werden können).

Unser oberster Grundsatz ist lediglich: Jede Bearbeitung sollte die Gesamtkarte ein kleines bisschen besser hinterlassen, als sie vorher war, wobei ein Rückbau im Detailgrad nur dann als „besser“ bewertet wird, wenn die Detaillierung faktisch falsch war. Wenn z.B. einzelne Bäume als kleine Polygone mit landuse=forest gemappt sind, kann man sie durch Nodes mit natural=tree ersetzen, weil ein Baum nun mal kein Wald ist.

Aber rein aus Geschmacksgründen wird hier nichts zurückgebaut.

--ks

Natürlich werden Kreuzungen deutlich komplexer, wenn man daran geht, Details einzuzeichnen wie die genauen Verläufe von Fuß- und Radwegen und durch Aufteilung bei baulich getrennten Fahrspuren.
Aber OSM ist halt keine Straßenkarte sondern eine Datenbank für viele Zwecke.
Ich habe aber beim Auto-Routing durch sauber gemapte Spurauftrennungen noch keine Nachteile gehabt. Routing-Apps stellen Straßen in der Regel derartig breit dar, dass man auf dem Kartenbild die Spuraufteilungen kaum wahrnimmt. Und wenn man die von Kreuzschnabel aufgelisteten Tipps beherzigt, werden von guten Routing-Apps auch keine Abbiegeansagen an jeder Verkehrsinsel gemacht.
Magic Earth hat damit überhaupt keine Probleme und OSM hat zwar grundsätzlich Probleme beim Anzeigen der Fahrspurpfeile, aber mit der Kartenansicht "Tourenansicht" ein sehr übersichtliches Kartenlayout fürs Autofahren, dass recht gut solches Detailmapping vereinfacht dargestellt bekommt.
Für Fußgänger und Radfahrer ist ein solche detailliertes Eintragen von Kreuzungen dagegen ein echter Mehrwert. Es ist bei komplexen Kreuzungen schon von Bedeutung, wo die Fußgänger hergeschickt werden. Ich selber freue mich durchaus, wenn mir auch Online-Planungstools wie outdooractive in Bereichen mit gut detailliert gepflegten OSM-Daten beim Planen einer Wanderung oder einer Laufrunde sogar anzeigt, wo ich die Straße überquere und auf welcher Straßenseite ich den neben der Straße verlaufenden Fußweg benutzen sollte.
Meine Erfahrung als Läufer und Wanderer: Es ist gerade dieser Detailgrad, die OSM deutlich attraktiver für diese Zielgruppe macht gegenüber Google-Maps. Denn Google-Maps ist mir deutlich zu autofahrerzentriert.

Galbinus wrote:

Für Fußgänger und Radfahrer ist ein solche detailliertes Eintragen von Kreuzungen dagegen ein echter Mehrwert. Es ist bei komplexen Kreuzungen schon von Bedeutung, wo die Fußgänger hergeschickt werden.

So isses.

Generell gilt: Software kann problemlos generalisieren (ein Renderer kann Spuraufteilungen für seine Darstellung wieder zusammenführen oder Abbiegerampen weglassen), aber sie kann nicht detaillieren. Deshalb liefern wir in den Daten lieber einen höheren Detailgrad als einen niedrigeren ab.

--ks

kreuzschnabel wrote:

Jeder mappt so, wie er/sie es für sinnvoll hält und wie es optimal an die Arbeit anderer Kollegen in der Umgebung anschließt. Wie detailliert eine Kreuzung in OSM abgebildet wird, ist Geschmackssache, und das wollen wir sogar so, solange die Daten nicht falsch sind (d.h. solange sie die reale Situation so abbilden, wie es den im Wiki festgelegten Vereinbarungen oder auch der normativen Kraft des Faktischen entspricht, so dass in allen denkbaren Auswertern ein ordentliches Ergebnis rauskommt).

Unterschiedliche Detaillierungsgrade sind kein Problem ... solange zusätzliche Details zusätzlich und mit eigenen Tags eingetragen werden. Aber wir sind weit davon entfernt, dass in allen denkbaren Auswertern ein ordentliches Ergebnis herauskommt. Denn dafür bräuchte man eben doch gut durchdachte Regeln, an die man sich auch überregional hält. OSM wird erst durch Auswertesoftware nützlich, und Auswertesoftware wird nicht für jede Stadt einzeln geschrieben – also braucht es ein einheitliches maschinenlesbares Datenmodell.

Ein Projekt wie Wikipedia kann es sich problemlos erlauben, große Unterschiede von einem Kleinstadt-Artikel zum nächsten zu haben, weil dort direkt ein fertiges Produkt erzeugt wird, keine Rohdaten. Der Text, den Wikipedianer verfassen, wird im Grunde 1:1 von Menschen gelesen, es findet nur sehr geradlinige Verarbeitung durch Software statt. Und in 99% der Fälle oder mehr ist es auch noch ein und dieselbe Software, nämlich die MediaWiki-Instanz, die auf wikipedia.org läuft.

OSM hat hingegen den Anspruch, keine bloße Karte, also kein fertiges Produkt, sondern eine Datenbank für verschiedenste Anwendungen sein zu wollen – sogar solche, die der Mapper selbst noch nie in Aktion gesehen hat. Leider funktioniert aktuell aber eigentlich nur geradliniges Rendering gut. Das liegt m.E. daran, weil hier der Abstand zwischen dem, was der Mapper im Editor tut, und dem Endprodukt am geringsten ist: Dort, wo der Mapper in seinem Editor eine Linie gemalt hat, malt der Renderer auch eine hin – ggf. halt gefiltert, mit anderer Farbe oder anderem Muster, aber letztlich doch ohne sich gar zu weit von den Eingangsdaten zu entfernen.

Automatisierte Generalisierung durch Software funktioniert nach meinem Eindruck keineswegs problemlos, sondern im Gegenteil nur schwer oder gar nicht. Dasselbe gilt für andere anspruchsvollere Anwendungsfälle. Und selbst dort, wo man mit viel Entwicklungsarbeit schöne Ergebnisse erzielen kann, will man sich einen solchen Zeitaufwand normalerweise nur leisten, wenn das Datenmodell ein solides Fundament darstellt, damit die lange Arbeit nicht durch die nächste Mappingmode obsolet wird.

i_am_a_burger wrote:

Um nochmal ein konkretes Beispiel zu liefern. Persönlich finde ich Google und Here bei dem folgenden Beispiel auch super. OSM's Daten würde ich ändern. Irgendwer muss einem doch sagen (können), ob ich das nun darf und was OSM's exakte Regeln sind

Leider gibt es noch keine exakten Regeln hierfür. Das liegt teils daran, dass OSM sich generell nicht leicht tut mit Entscheidungsfindung (bisweilen auch absichtlich, weil wir Dezentralisierung und Do-ocracy mögen). In diesem Fall liegt es zusätzlich aber auch daran, dass ein für unterschiedlichste Anwendungsfälle geeignetes aber trotzdem laientaugliches Datenmodell für Straßen sehr viel Arbeit und Gehirnschmalz braucht.

Daher habe ich leider auch noch keinen konkreten Vorschlag in der Schublade. Aber der Vorstellung, dass wir nach Gefühl mappen können und Software es auch ohne präzises Datenmodell schon irgendwie verstehen und generalisieren können wird, muss ich dann doch widersprechen. Solange es Geschmackssache ist, wie eine Kreuzung abgebildet wird, wird OSM sein volles Potential nicht entfalten können.

Tordanik wrote:

Solange es Geschmackssache ist, wie eine Kreuzung abgebildet wird, wird OSM sein volles Potential nicht entfalten können.

Das stimmt. Ich habe auch nicht den Idealzustand beschrieben, sondern den status quo. Und ob du eine Kreuzung nur mit zwei Ways und einem shared node erfasst oder alke Aufteilungen und Rampen einbaust, ist momentan dir überlassen. Es darf nur nicht falsch sein.

Dass ein Konsens nicht einfach wird, zeigt sich ja hier in der Diskussion - der eine mags einfach, der nächste ausführlich.

--ks

kreuzschnabel wrote:

@Ausgangsfrage: Wenn die Datenlage in OSM faktisch falsch ist, darfst, sollst du sie natürlich ändern ... Aber rein aus Geschmacksgründen wird hier nichts zurückgebaut.

Ich will ja nicht patzig werden, aber meine Frage war ja eben, ob es ein Dokument gibt, das mir erklärt, was richtig und falsch ist. Gefragt habe ich, weil in Hamburg learning by gucking halt nicht funktioniert. "Darstellen obliegt dem Renderer" ergibt da auch gar keinen Sinn. Wenn alle unterschiedlich Kreuzungen angehen, hat man, shit in, shit out, halt so 'ne kunterbunte Grütze:

Galbinus wrote:

Ich habe aber beim Auto-Routing durch sauber gemapte Spurauftrennungen noch keine Nachteile gehabt.

Vielleicht interessiert dich dieser Post ja. Ich kann viele Standpunkte hier grundsätzlich verstehen. Aber wenn man sich überlegt, dass die gesamte Autoindustrie an einem standardisierten Format für Kartendatenbanken arbeitet, dann hat es auch was albernes, wenn einem Erwachsene erzählen wollen, dass OSM > (Google+Here)², wenn die Frage nach internen Standards schon lästig ist. Zumal, wie sollte man bei den Kreuzungen oben etwas verändern. Jeder Freiwillige hat ja nichts verkehrt gemacht...

i_am_a_burger wrote:

Ich will ja nicht patzig werden,

- wirst Du aber genau mit diesem Satz.

i_am_a_burger wrote:

Vielleicht interessiert dich dieser Post ja.

keine Ahnung, ob der mich interessiert, mein Englisch ist nicht gut genug, um das ohne sehr großen Aufwand verarbeiten zu können. Und ich gehöre im Moment nicht zu denen, die wegen Kurzarbeit mehr Zeit als sonst haben sondern im Gegenteil zu denjenigen, die Dank Corona mehr als sonst um die Ohren haben.
Es kann natürlich sein, dass es Routingprobleme gibt. Ich habe mich ausdrücklich auf meine persönlichen Erfahrungen mit Magic-Earth und Osmand+ bezogen. Und ich habe auf die von Auto-Routing abweichenden Interessen von Wanderern hingewiesen. Das ist halt der Unterschied zwischen OSM und den Interessen der von Dir angeführten Autoindustrie. Und auch Google hat andere Schwerpunkte und Intentionen als OSM. Das ist erst einmal so und lässt sich nicht so einfach auflösen.
Und dazu kommt, dass bei einem quasi anarchistischen Projekt wie OSM es halt in vielen Fragen nicht die eine, einzige Antwort auf die Frage gibt, was richtig und falsch ist.
Ob das, was Du da als Foto-Kollage zusammengestellt hast, wirklich qualitativ so schlecht ist (

i_am_a_burger wrote:

so 'ne kunterbunte Grütze

) kann ich nicht auf einen Blick überprüfen, da ich dazu erst einmal jede der Kreuzung anhand von Luftbildern mit der Realität vergleichen müsste. Aber so auf den ersten Blick finde ich nicht, dass dies komplexen Kreuzungen wirklich so schlecht sind. Denn wenn eine Kreuzung tatsächlich komplex gebaut ist (mit diversen baulichen Trennungen) und es sich nicht lediglich um "Spurmapping" handelt, dann bezweifele ich, dass eine Vereinfachung wirklich so viel vorteilhafter wäre.

i_am_a_burger wrote:

dann hat es auch was albernes, wenn einem Erwachsene erzählen wollen, dass OSM > (Google+Here)²

Albern ist es aber auch, wenn du sachlich richtige Aussagen nimmst und ins Lächerliche ziehst, um deine Position zu stützen. Das oben Angeführte hat natürlich niemand gesagt, und ich wüsste hier auch niemanden, der es sagen würde. Dass wir millionenschweren Platzhirschen mit einem Low-Cost-Liebhaber-Projekt nicht ernsthaft Marktmacht entgegensetzen können, ist uns ziemlich klar. Wir versuchen es deshalb mit Qualität. Vermutlich beziehst du dich auf uvis Aussage

uvi wrote:

OSM ist eben eine Datenbank, die meist/möglicherweise mehr Daten beinhaltet als Google-Maps oder HERE.

… und da hat er vollkommen recht, weil OSM viel breiter aufgestellt ist. Google und Here haben nicht den Ehrgeiz, Sitzbänke, Zigarettenautomaten und Hundekotbeutelspender zu erfassen. Nicht mal Feldwege 🙂

OSM soll eine Karte für alle sein, nicht nur für Autofahrer. Und da liegen wir ziemlich gut im Rennen.

Nochmal zur Frage: Ich persönlich würde einen einheitlichen Standard für Kreuzungen sehr begrüßen – nämlich den, den ich sinnvoll finde und anwende. Und da fängt dann auch schon das Problem an 😄

Und nein, über das OSM-Wiki hinaus gibt es so ein Dokument nicht. Alles andere regelt gesunder Menschenverstand. Frage beantwortet?

--ks

i_am_a_burger wrote:

[...] und wann eine Strasse zu zwei Ways OSM werden muss [...]

Die wiki beschreibt wie es gemacht wird, nicht unbedingt wie es gemacht werden muss, aber zu diesem Thema gibt's wohl schon paar Threads und hier die wiki-Stellen, die ich mir mal notiert hatte (gebe zu diese sind nicht so auf die Schnelle zu finden - im wiki darf jeder schreiben, wenn Du magst mache gerne eine schöne Übersicht draus 😉 ):

https://wiki.openstreetmap.org/w/index. … ten_Spuren
https://wiki.openstreetmap.org/w/index. … nte_Linien
https://wiki.openstreetmap.org/w/index. … lussrampen

i_am_a_burger wrote:

Ich will ja nicht patzig werden, aber meine Frage war ja eben, ob es ein Dokument gibt, das mir erklärt, was richtig und falsch ist.

Naja, etwas patzig klingt das schon, zumal man Dir bereits mehrfach geschrieben hat, dass es kein solches Dokument gibt, das richtig und falsch definiert. Neben den bereits geschilderten Gründen liegt das auch daran, dass gerade die größeren und komplexeren Kreuzungen immer im Einzelfall betrachtet werden müssen, da jede so ihre Eigenheiten hat.

Es hat sich trotz fehlender klarer Festlegung dennoch ein gewisses best practice entwickelt, jedoch auch typische Unarten. Mit der Zeit entwickelt man auch ein gewisses Gefühl dafür, auch durch learning by gucking. Die Gewichtung kann jedoch von Mapper zu Mapper verschieden sein.

Zu deinen Beispielen in Beitrag #21 meine ganz persönliche Meinung:
Bild 1 Eimsbütteler Marktplatz:
- sämliche Verbindungen der tertiary zur primary als tertiary_link ist in meinen Augen eher schlechtes Mapping. Besser wäre, die tertiary direkt an die primary anzuschließen. *_link war ursprünglich für echte Auffahrten über Rampen vorgesehen. Dass man sie heutzutage auch für Rechtsabbiegerspuren verwendet ist m.E. ok, hier wurde aber übertrieben.
- Rechtsabbiegerspuren sollten nur gemappt werden, wenn diese baulich getrennt sind - das wäre hier nicht der Fall
- die ganzen tertiary_link tendieren bereits sehr stark zu Spurmapping. Ich persönlich wäre hier geneigt, in Teilbereichen stärker zu generalisieren
- die Abbiege-Restriktionen sind nicht konsequent umgesetzt. Theoretisch ist ein Routing möglich, das in der Realität so wahrscheinlich nicht vorgesehen ist. Graphhopper routet von der Lappenbergsalle nach links in die Heußstr., obwohl Linksabbiegen nicht erlaubt ist. Das ist meistens eine Folge davon, wenn man eine Kreuzung zu detailliert mappt.
Bild 2 Kennedybrücke: finde ich insgesamt recht gelungenen Kompromiss zwischen Detail und Generalisierung.
Bild 3 Holstenplatz: ebenso
Bild 4 Lehmweg: die tertiary Lehmweg hätte ich an beide Richtungsfahrbahnen der Hoheluftchaussee angeschlossen
Bild 5 die secondary Königstraße wäre genauso über beide Fahrbahnen der Max-Brauer-Alle, so wie in Bild 6 die Ehrenbergstr.
Bild 6 finde ich gut gelöst
Bild 7 prinzipiell gut gelöst, jedoch würde ich die Rechtsabbiegerspur von der Poststr. in die Ehrenbergstr. nicht als secondary_link mappen. Ich halte das für eine Unart, die auf eine undiskutierte Änderung im wiki beruht
Bild 8 von dem Linksabbieger der Kaistr. in die Palmaille würde ich _link entfernen, diskutieren kann man, ob der Rechtsabbieger verzichtbar ist.
Bild 9 hier würde ich sogar Rechtsabbieger einbauen, wenn keine bauliche Trennung vorhanden, um zu scharfes Rechtsabbiegen zu vermeiden. Ist ansonsten aber in ihrer Komplexität gut gelöst und vor allem aktuell.