Komplizierte Kreuzungen zum Testen des Area=highway

Marek, ich weiß nicht, ob du meinen Vorschlag zur Lösung des Spurmapping-Problems unter https://wiki.openstreetmap.org/wiki/User:Fabi2/Generic_lane_model mitbekommen hast. Ich habe den gepostet, in der Hoffung, das den interessierte Spurmapper vielleicht durchsehen und weiter verbessern, weil ist bestimmt noch nicht voll konsistent und fehlerfrei. Im Grunde ist es auch nur eine Versuch, meinen schon beschriebenen Lösungsweg mal testweise umzusetzen.

Das ganze ist doch im Grunde genommen ganz einfach:
Wenn man die Spur als Abstraktionsstufe ansetzt, so ist die höchstmöglichst mappbare Detailstufe, die Spur als Fläche zu mappen. Es hat auch keinen Zweck dei der Abstraktionsstufe Fahrbahn (area=highway) zu beginnen, wenn man eigentlich noch eine Stufe weiter ins Detail auflösen will. Die Straße enthält mehrere Fahrbahnen (unterschiedlicher Breite (getrennter Fuß-/Radweg=1 Fahrbahn mit 2 Fahrspuren) und für unterschiedliche Nutzungsarten) und diese können aus einer oder meheren Spuren bestehen. Wenn man die Fläche der Fahrspur nicht mappen kann oder möchte, abstrahiert man die Fahrspur ersatzweise (und zu ihrer Fläche austauschbar) zu einer Linie.

Gegenüber der Fläche, hat man da den Vorteil, das die Linie/Vektor (OSM-Way) ja nur 4 Seiten hat vorwärts (=in Richtung des Linienverlaufs), rückwärts, links und rechts, was auch gilt, wenn sie ein geschlossener Kreis (junction=roundabout) ist. Damit läßt sich bei einem Way auch leicht angeben, wer in welche Richtung fahren darf. Im Vorschlag ist es für jeden Way gemacht, aber wenn man sowieso eine extra Editor oder Tools für das Schema braucht, sind das sicher Relationen, wo man das für mehrere Wege zusammenfassen kann, besser.

Mehrere Fahrspuren sind dann die jeweilige Fahrbahn und eine oder mehrere Fahrbahnen dann die Straße. Das Hauptproblem bei flächigen Spuren ist ja, die möglichen Übergänge zwischen den Spuren abzubilden. Meine erste Idee war da einfach das betreffende Wegstück in eine Relation zu stecken und dann kann man für den Weg aus gemeinsamen Knoden ja wieder angeben, wer da von links und von rechts drüber/fahren oder gehen darf.

Obige Lösung ist Proof of Concept von meiner Lösung, deshalb ist da auch nicht unbedingt alle vollstänig und korrekt durchgetaggt. Weil wenn man nämlich jede Spur mappt, ist egal, ob sich vielleicht ein Teil der Kreuzung unter der Erde befindet. Außerdem spart man sich bei den 4-Richtungen einen haufen Relationen mit Abbiegebeschränkungen.

Hallo Fabi2,
ich habe auch darüber nachgedacht ob man nicht gleich besser die einzelnen Spuren als Flächen mappt, aber ich befürchte, dass es niemand auf einer Autobahn durchhält. Ich denke mir fast, dass wir für die Diskussion einige Testbereiche wählen sollten und dort verschiedene Schemata testen. Daraus würde sich der Aufwand ergeben sowie Vor- und Nachteile von jedem Ansatz.

Wenn das so ist, dann plädiere ich dafür dass man solche Linine nicht miteinander verbindet. Die momentane Lösung ist fehleranfällig und für den Routing tödlich. Es produziert Unmengen an Relationen und unnötiger Arbeit.

Zu dem schon ziterten Bild: http://wiki.openstreetmap.org/wiki/File:MarekGeneralizationCrossing4.jpg ein Beispiel in der Karte: http://osm.org/go/0Oc0xvZVn

Ich habe testsweise untersucht, was man aus den Straßenflächen mit entsprechendem Rendering rausholen kann.
Hier ein Beispiel:
http://wiki.openstreetmap.org/wiki/DE:Street_area#M.C3.B6glicher_Rendering_der_Stra.C3.9Fenfl.C3.A4chen_unter_Ber.C3.BCcksichtigung_anderer_Elemente_der_Karte

Bitte dort Bild C. mit D. vergleichen…

Ein User hat schon die Tests für einen Renderer angefangen: http://znajomy.home.pl/area/index2.html

Ihr wisst abr schon, dass Luftbilder schon erfunden worden sind?

SCNR

Wir kommen von “komplizierten Kreuzungen” und “Spurmapping” auf sowas? Das ist doch Mapping für den Renderer - hat aber nix mit der Vereinfachung oder idealen Darstellung von Kreuzungen zu tun…

Also ich verstehe das nicht ganz (muss ich vielleicht auch nicht…)

na ja, auf den Luftbilder sind die unterirdische Bereiche gewöhnlich ein wenig unterrepresentiert.
Außerdem sind wir nicht der Eigentümer der Luftbilder deswegen rendern wir auch jetzt Karten.

Generell wo ist die Grenze zwischen dem A. Mapping für den Renderer und der B. Abbildung der Realität?

Je detailliereter Du die Realität abbildest, umso mehr kann der Renderer damit anfangen.

Mapping für den Renderer ist einfach nur, dass man Dinge absichtlich falsch einträgt, damit sie in speziellen Renderern auf eine bestimmte Art dargestellt werden.

Bei deinem Beispiel könnte man zum Beispiel den Fußweg als cycleway eintragen, damit eben keine Zebrastreifen angezeigt werden. Oder das man footways mit ganz kleinem width als Mittelstreifen einträgt, oder oder…

Dann siehe ich diese Gefahr bei dem Konzept nicht :wink:

Ich würde im Falle echter Straßen nicht von der bisherigen Regel (gemeinsamer Knoten bei physischer Verbindung ist unabhängig von den erlaubten Abbiegemöglichkeiten ein Muss) abweichen wollen.

Meiner Meinung nach etwas anders läge die Situation bei “Spurways” innerhalb einer Kreuzungsfläche, wenn auch die Kreuzungsfläche als solche eingezeichnet ist. Diese dürften sich dann gerne auch ohne gemeinsame Knoten schneiden. Cobras Beispiel sieht auf mich wie ein behelfsmäßiger Versuch aus, eine solche Darstellung mit den bisherigen highway-Tags nachzubasteln, allerdings halt ohne die Kreuzungsfläche.

Eigentlich fände ich auch bei einer solchen Idee mit Spurways eine zusätzliche highway-Area extrem hilfreich. Sie würde einen definierten Übergang zu Straßenstücken ohne Spurways schaffen - die Spurways müssten dann immer mit gemeinsamen Knoten zu einer Flächen-Trennkante beginnen. Ein Renderer wird womöglich auch auch die “Spuren” in einer Kreuzungsfläche, die sich überschneiden können, anders behandeln wollen als die entlang eines Straßenstücks. Eventuell könnte man mit den Flächen sogar auf eine Relation zum Zusammenfassen der Spurways verzichten, da sich die Zusammengehörigkeit ja aus der Lage in einer gemeinsmen Highway-Fläche ergibt.

Allerdings bin ich von der Idee, Spurways entlang von Straßen einzuzeichnen, generell noch nicht wirklich überzeugt. Die Alternative (Mittellinie mit Spurtags + Straßenfläche bei unregelmäßiger Breite und komplexen Kreuzungen) macht nicht nur vielerorts deutlich weniger Arbeit, sie produziert auch optisch saubere Resultate. In dem von Fabi2 verlinkten Beispiel schwanken die Abstände zwischen den Spurways wegen der unvermeidlichen Ungenauigkeit beim Zeichnen beachtlich, das würde man m.E. nicht so fürs Rendern verwenden wollen.

Hallo Tordanik, könntest Du eine, zwei Skizzen machenm, die diese Idee veranschaulichen?
Viele Grüße,
Marek

Warum hast du - direkt entgegengesetzt zu den Beispielen oben auf der Seite - ein Sternmapping hergenommen? Das ist eine sehr seltsame Lösung, die selbst auch etliche Probleme erzeugt. (Meiner Meinung nach ist das die mit Abstand schlimmste Lösung von allen)
Sonst hast du auf der Seite konsistent die Fahrspuren annähernd so, wie sie wirklich laufen. Ich finde, das verwirrt unnötig.

Gegenfrage: welchen Renderer meinst Du? Wenn man für den Renderer mappen will, müsste man dafür sorgen, dass man alle Renderer berücksichtigt (könnte aber relativ schwierig werden).

Hätte auch noch was schönes, die sogenannte “Binger(-brücker) Darmverschlingung”:

http://www.openstreetmap.org/?mlat=49.963653&mlon=7.88961&zoom=18&layers=M

http://maps.google.de/maps?q=Bingen&hl=de&ll=49.963468,7.890136&spn=0.002809,0.008256&sll=51.175806,10.454119&sspn=11.221868,33.815918&hnear=Bingen,+Rheinland-Pfalz&t=k&z=18

Hallo Cobra,
es ist genau das, was Du schreibst: ein schlechtes Beispiel, seltsame Lösung die wir mal leider immer wieder treffen. Ich habe es absichtlich genommen um zu zeigen, dass beim schlechten Mapping auch schlechter Rendering rauskommt.

Eine Bearbeitung der Flächen führt - dessen bi ich mir mittlerweile sicher - zu einer nachträglichen Verbesserung der Karte. Warum? Wer die Flächen nachzeichnet, merkt meistens was an den Vektoren chlichtweg falsch ist. Eigentlich war dieses Beispiel genau dafür gedacht. Du hast aber recht, an dieser Stelle und mit diesem Kommentar verwirrt es eher. Ich werde es ersetzen sobald ich ein anders Beispiel generiert habe.

Es würde schon deutlich verständlicher werden, wenn du dazu schriebst, dass deine Bilder nicht aus den Daten gerendert wurden, die du oben als Rohdaten zeigst.

Hallo Aighes,
selbstverständlich, die Daten werden aus den Areas gerendert. Ich hab´s ergänzt…

Vorschlag für die (optionalen) Spurways?
z.B.
lane=secondary oder
highway=secondary_lane oder
lane:secondary=left_turn
?

Würde gerne meine spurgemappte Nachbarstadt entsprechend umstellen. (Bisher hab ich bei Routingfehlern die überflüssigen
als highway gemappten Spuren entfernt).
Chris

Um die Stimmung anzuheizen: User Dtevo und Pbabik werkeln an einem Renderer für sowas + indoor mapping…( wie z.B. hier: http://osm.org/go/0PMfQ2NvC– )

Die Idee wäre noch eine Stufe mehr auf dem eigenen PC zu rendern, da die Informationsdichte wesentlich höher ist, und die gerenderten Kacheln upzuloaden.
vorteil: Keine Wartezeit, Entlastung von dem zentralen Server…

Was spricht gegen den bewaehrten secondary_link in Kombination mit turn:[left|right|through|…]? Eigentlich ist so eine Spur doch genau das: Ein link zwischen zwei Highways mit vorgeschriebener Fahrtrichtung.

Na ja, ich würde gerne highway=* für echte baulich getrennte Fahrbahnen behalten.
Die kreuzungsinternen Link-Spuren (siehe Marek’s Bild) sind ja nur eine Art Verfeinerung, die ein Router z.B. aus Performancegründen
(oder für die Ansage-generierung) ignorieren könnte.

Wirklich ignorieren kann er sie nicht - die Spuren sind ja die einzige Möglichkeit von A nach B zu kommen.
Für die Ansage sollte so eine Spur ähnlich wie ein einziger Knoten behandelt werden bei der Bestimmung der Abbiegerichtung (siehe meine Fragen vor 2 Wochen).
Die ganzen nicht baulich getrennten Spuren bräuchte es ja nach Einführung von area=highway nicht mehr. Der Grund für das Spurmapping ist ja im Moment nur die Optik und das Problem gibt es dann nicht mehr - das wären wieder nur lanes eines highways.