Germany/Workshops/Linienbündel

Text von AndreR, erweitert von Mueck

Problematik

Status quo im Jahr 2008:

• Es gibt keine zufriedenstellende Lösung zum Erfassen/Attributieren/Rendern/Routen von gebündelten linienhaften Objekten, wie straßenbegleitenden Rad-/Fußwegen/Anliegerstr., Bahnen zwischen/auf/neben Fahrbahnen und allgemein benachbarte Objekte (Verdrängungsproblematik), ebensowenig für das Erfassen/... mehrspuriger/mehrgleisiger Objekte.

Lösungsansätze:

1. Die Wege einfach (auf bisherige Art) separat erfassen

• Vorteile
  • einfaches Taggen der Einzelwege
    • Bsp.: fahrtrichtungsabhängige Tags (Radweg links, Radspur rechts, Tempolimit oder Lkw-Verbot nur stadteinwärts)
  • komplexe geometrische Zusammenhänge einfacher erfassbar
    • Bsp.: Kurze Unterbrechungen oder größere Verschwenkungen von Radwegen sind einfacher erfassbar
    • Bsp.: komplexe Kreuzung -- Autos werden völlig anders geführt als Radfahrer, andere Abbiegerestriktionen abh. vom Verkehrsmittel, Fußgänger evtl. nur via Unterführung: Routing kann Einzelwege fahrzeugabhängig besser routen bei seperater Erfassung der Einzelwege
  • formal genaueres Abbild der Realität

• Nachteile
  • unübersichtlich beim graphischen Editieren durch Gewühl von Wegen
  • an jedem Abzweig korrektes Verbinden der einzelnen Wege untereinander und mit Querwegen notwendig zum korrekten Routen
    • Bsp: Wie sollen unzählige Überquerungsmöglichkeiten der Fahrbahn für Fußgänger erfasst werden.
  • Render-Ergebnisse derzeit nur sehr bescheiden...
  • Für Router derzeit sind Zusammenhänge zwischen Haupt- und Nebenfahrbahnen derzeit nicht erkennbar
    • Zusammenhänge müssen über Relationen wieder hergestellt werden.
      • via role müsste die Funktion zugeordnet werden: Bspw. 0 = Bezugsgeometrie für weitere Bearbeitung, -1, 1, 2, ... ähnlich wie in 3. für Reihenfolge ab Bezugsgeometrie; oder: automatische Detektion der Reihenfolge jenseits 0

2. Die Wege auf einfache (bisherige) Art als Attribut an die Straße hängen

• Vorteile:
  • Gut auswertbar für Router. Allerdings müssen alle Router die Syntax lernen und die muss wachsen wenn es weitere Attribute für die "Spuren" gibt.
  • Einfache Geometrie zum Rendern (allerdings größere Abweichung des gerenderten Bilds von der realen Situation)
• Nachteile:
  • Starke Zersplitterung der Wege in kleine Abschnitte, immer wenn sich Attribute ändern.
  • evtl. unübersichtlich beim graphischen Editieren, weil den Tags keine grafische Entsprechung zur Seite steht. Einzelne Nachteile:
    • Fehler werden nicht erkannt, da nicht visuell "von weitem" erkennbar, sondern zu jedem Way erst die Tags gelesen werden müssen.
    • Es werden latent zu viele Verbindungen erzeugt, da nicht jede einzelne Spur in der Realität auch an jedem Knoten mit allen anderen Spuren verbunden ist. Falsche Verbindungen werden leicht versehentlich erzeugt, und dann nicht erkannt (s.vorheriger Punkt)
    • wenn doch grafische Entsprechung, ist das Bild genauso unübersichtlich oder nicht wie einzeln gemappte Spuren auch.
  • Es ist derzeit nicht möglich, für diese Unterwege abweichende Attribute anzugeben.
  • Richtungsabhängiges Taggen schwierig. Umdrehen des ways gefährlich. Weder left/right noch die Angabe als Himmelsrichtung konnten bisher einen Großteil der Teilnehmer der ML überzeugen.

3. Vorschläge um Spuren/Wege auf komplexe Art an einem Way zu taggen

• Bsp.: (genaue Syntax müsste noch erarbeitet werden)

highway=primary (Hauptfunktion)

name=Fritz-Müller-Boulevard

way.0:landuse=green (Grünstreifen in der Mitte) oder

way.0:railway=tram (Straßenbahn in der Mitte) oder

way.0=none (nix, nur weiße Linie)

(Gesamtgeometrie des ways beziehe sich im Beispiel sich auf die Mitte, daher 0. 0 könnte auch was anderes sein, wenn Geometrie auf anderem Teilweg abgefahren)

way.1:highway=primary und way.1:lanes=2 "zweispurige Fahrbahn in die eine Richtung" oder

way.1:highway=primary:lane.1

way.2:highway=primary:lane.2

way.1:goods=no (keine Lkws auf linker Autobahnspur)

way.-1:highway=... dasselbe für die Gegenfahrbahn

way.3:amenity=parking für den Parkstreifen

way.4:landuse=green paar Blümelscher daneben

way.5:cycleway=track

way.5: noch was für Freigabe in beide Richtungen

way.6:footway=track

way.-3:highway=lane oder so... ein Seitenstreifen

way.-4:landuse=green auf der anderen Seite kein eigentlicher Radweg, dafür:

way.-5:highway=residential ... eine Anliegerfahrbahn.

way.-6:footway=track

way:-7:waterway=stream für einen ständig wasserführenden Graben oder Bach neben der Straße...

• Ähnlicher Vorschlag:

Darstellung Mittelstreifen und Seitenbereiche über right. left. und middle.

• noch ein ähnlicher Vorschlag

highway=primary (für die Renderer; Router sollten die lanes auswerten)

name=Hauptstraße

lane:a = pedestrian

lane:a:surface = gravel

lane:a:crossing = restricted (Straße kann nur an Ampeln überquert werden)

lane:b = bicycle

lane:b:surface = bricks

lane:b:crossing = restricted (Straße kann nur an Ampeln überquert werden)

lane:c = barrier

lane:c:barrier = fence

lane:d = road

lane:d:highway = primary

lane:d:direction = opposite

lane:d:speed_limit = 60 km/h

lane:e = bus

lane:e:direction = forward

lane:e:speed_limit = 60 km/h

Die Spuren in diesem Versuch eines Datenmodells gehen von links nach rechts in Richtung des Wegs. Wenn man die Richtung eines Wegs umdreht, sollte ein Editor nachfragen, ob er die Reihenfolgen und Richtungen der lanes mitdrehen soll oder nicht.

• Vorteile:
  • fahrstreifen-/teilwegabhängige Attributierung relativ problemlos (Einordnen für Navis, fahrstreifenabh. Limits, ...)
  • Geometrie bleibt einheitlich für alle ways
  • Zusammenhang der Gesamtstraße (hat sie Radwege oder nicht?) stets zusammenhängend ohne Relationen

• Nachteile:
  • unübersichtlich beim Editieren der Attribute durch Unmengen an Tags
  • komplexe geometrische Zusammenhänge sehr schwierig ode gar nicht darstellbar (unterschiedliche Wegeführung/Abiegerestirktionen für Autos/Räder)

4. Kombinationen aus den Methoden 1-3

• bspw. bei:
  • Tram auf Fahrbahn kann auch im komplexen Modell 3 zu Doppelbelegungen führen:

way.1:railway=tram

way.1:highway=primary:lane.1

way.2:highway=primary:lane.2

... wäre ein real existierender Fall: Karlstraße in Karlsruhe, in einigen Abschnitten, way.2 tw. legal, tw. illegal beparkt...

• • bei separten ways für Tram-, Kfz- und Radverkehr können trotzdem die Einzelways weiter nach Modell 3 spezifiziert sein, um bspw. für die Kfz fahrstreifenabhängige Limits abzubilden

• Einige reale existierende Begebenheiten können vernünftig nur mit Modell 1 abgebildet werden, andere nur mit Modell 3, daher vermutlich keine entweder/oder Entscheidung möglich, sondern Koexistenz?

• Bei Wahlfreiheit zwischen den Modellen

• • Abgrenzungsfrage: Wann ist ein Weg straßenbegeleitend? Für mich als Radfahrer ist eine große Straße machmal ein echtes Hindernis.

5. Die Wege mit einer Relation-Hierarchie an die Straße hängen

Grundgedanken:

• Wie Vorschlag 3 nur hierarchisch – ein Teilweg (z.B. Autofahrbahn) kann sich wiederum in Teilwege (z.B. Spuren) untergliedern
• Tags von höheren Ebenen werden auf untere Ebenen „vererbt“ (etwa der maxspeed von der Fahrbahn auf die einzelnen Spuren)

Es folgt ein Beispiel zu Tags und Member-Beziehungen – eine simple zweispurige Tempo-30-Straße mit Gehsteig auf beiden Seiten und einem in beide Richtungen befahrbaren Radweg auf der fahrbahnnahen Seite eines der Bürgersteige. Tag-/Membernamen und Details erheben keinen Anspruch auf Ausgearbeitetheit. Es ist außerdem natürlich nicht erforderlich, eine Straße voll auszumappen. Interessieren nur Radwege, lassen sich die Autospuren getrost weglassen.

Grafische Darstellung der verschachtelten Relations

• Way W4711:

mit normalem Tagging zwecks Kompatibilität versehen, ansonsten keine Attribute

• Relation R1:

Tags:

• type = lane

Member:

• way – W4711
• -1 – R2
• 0 – R5
• 1 – R8

• Relation R2:

Tags:

• type = lane

Member:

• 0 – R3
• 1 – R4

• Relation R3:

Tags:

• type = lane
• lane = sidewalk //impliziert access=no, foot=yes

• Relation R4:

Tags:

• type = lane
• lane = bicycle_lane //impliziert access=no, bicycle=yes

• Relation R5:

Tags:

• type = lane
• maxspeed = 30 //wird auf R6 und R7 vererbt

Member:

• -1 – R6 //die member-Rollen geben eine relative Ordnung an, von links nach rechts in Way-Richtung
• +1 – R7

• Relation R6:

Tags:

• type = lane
• lane = car_lane
• direction = backward //nur gegen Richtung des Ways befahrbar

• Relation R7:

Tags:

• type = lane
• lane = car_lane
• direction = forward //nur in Richtung des Ways befahrbar

• Relation R8:

Tags:

• type = lane
• lane = sidewalk

Vorteile:

• Relations können anders als Tags wiederum Member von Relations sein, etwa für Abbiegevorschriften auf Spur-Ebene (dadurch auch fahrzeugabhängig korrektes Kreuzungsrouting)
• Tagging an beliebiger Stelle der Hierarchie möglich, fahrtrichtungsabhängige Tags etc. daher kein Problem
• weniger Aufwand beim Umsortieren, da Nummer nur an einer Stelle zu ändern ist, nicht an jedem Tag
• Kartenansicht im Editor wird nicht belastet, nur der aktuell bearbeitete Way braucht im Detail dargestellt werden
• die Tags der einzelnen Lanes bleiben für sich genommen übersichtlich bearbeitbar

Nachteile:

• die Gesamtstruktur ist unübersichtlich und ohne Zusatztools nicht auf einen Blick zu erfassen
• ohne besseren Relation-Support in Editoren ist effizientes Editieren in größerem Stil unmöglich
• keinerlei bestehender Renderersupport

Potentielle Erweiterungen:

• Kombination mit Vorschlag 1 durch Ergänzen von zusätzlichen Ways für die niederen Hierarchieebenen. Die Relationen erledigen so auc das „Zusammenbinden“.
• Divider als weiteren Membertyp „zwischen“ Relationen => Grünstreifen, Leitplanken, Streifen auf der Fahrbahn, …

Weitere Fragen und Anwendungen bzgl. Linienbündel

Bahn

• Problem Gleiszahl:
  • tracks=2 einfache Lösung, Haken: sobald Verbindungen zwischen den beiden Gleisen erfasst werden sollen, wäre die Erfassung ohne eigene ways für jedes Gleis äußerst knifflig.
  • Standardkarten sollten aus den 2 (oder mehr) einzeln erfassten Gleisen nur eine gerenderte Linie machen, müssten parallele ways umrechnen,
    • ggfs. mit unterschiedlichen Symbolen für ein-/zweigleisig: osmarender hat bspw. eine schwarze Doppellinie für railway=rail mit einzelnen Querstrichen als Eisenbahnstreckensymbol, zwei statt einem Querstrich könnte Zweigleisigkeit darstellen. Mapnik hat schwarz-weiße Blöcke, ein zusätzlicher Querstrich im weißen Block könnte Zweigleisigkeit sein. Beides schon mal in Papierkarten gesehen.
  • Spezialbahnkarten sollten gleistreu darstellen können, müssen tracks=2 daher umrechnen

enge Täler

• Fluss, Straße, Eisenbahn, Feld- und Waldwege können sich in engen Tälern überlagern in entsprechenden Zoomstufen.
  • Alles in eine Relation gepackt und der Renderer könnte, ausgehend von einem als 0 = Bezugslinie definierten way, die anderen ways wegschieben bei Bedarf.

Häuser und Sackgassen nahe der Straße

• ganz ähnlich könnten Verdrängungen von Häusern, Sackgassenenden und anderen Objekten zeichnerisch gut gelöst werden, wenn man sie mit in die Relation packt.

Rendern

Beschränkungen von SVG, Rendern allgemein

• SVG wird zumind. bei osmarender als Zwischenstufe verwendet.
• Doppellinien etc. müssen "getrickst" werden:
  • eine secondary mit oranger Füllung und dunklen Begleitstrichen ist real in SVG:
    • eine dickere dunkle Linie "unten" und
    • eine dünnere orange Linie "oben" drüber, die die dickere Linie unten so verdeckt, dass sie als zwei Begleitlinien erscheint, in OSM "casings" genannt.

• Wie straßenbegleitende (Rad-)Wege darstellen?
  • naheliegende Idee: statt normaler (dünner) grauer casings dickere blauere casings.
  • Problem dabei: sobald in beide Richtungen unterschiedlich (Radweg nur linksseitig) funktioniert der SVG-Trick nicht mehr, eine Linie mit offset in Relation zu einer anderen Linie zeichnen geht nicht
    • jedes casing müsste per eigener Geometrie definiert werden, die aus Bezugsgeometrie abgeleitet wird mit errechnetem offset zu dieser.
    • dasselbe gilt für alle Elemente, die im einen way vereinigt sind (Methode 2 und 3) oder die bei Methode 1 zuvor zusammen gefasst werden.

Möglicher Gesamtablauf für Methoden 1 bis 3 und Kombinationen daraus

• Schritt 1: Bei Relationen der Methode 1:
  • alle Elemente einsammeln
  • wenn Elemente mit role=0 vorhanden: das ist die künftige Bezugsgeometrie
  • wenn nicht, Geometrie aus -1 und 1 mitteln
  • wenn keine roles angegeben oder lückenhaft:
    • Bezugsgeometrie erraten, aus höchster Straßenklasse (eine Fahrbahn) bzw. Mitte aus zwei höchstklassigsten Fahrbahnen oder tram in der Mitte etc.
    • ermitteln, welche Elemente parallel dazu laufen und sortieren nach -2, -1, 1, 2, ...
    • ggfs. zusammenfassen (zwei Gleise zu einem Symbol, ...)

• Schritt 2: dann von der Mitte her jeden einzelnen Linienzug nach Methode 2/3 betrachten (ways außerhalb Relation: nur dieser Schritt):
  • Methode 2 ggfs. in 3 wandeln
  • darzustellendes (Gleis auf/neben Fahrbahn, Radwege, ...) von nicht darzustellendem (n Fahrspuren gleicher Klasse werden mit einem Symbol dargestellt) trennen, sortieren
  • Darstellungsart, Linienstärken und Farben der zu zeichnenden Elemente bestimmen
  • für jede zu zeichnende Linie aus der Stärke der benachbarten Linie den Offset zur Mitte berechnen

• Schritt 3: dann ggfs. benachbarten extra erfassten Linienzug betrachten
  • dessen Geometrie liegt zu nahe dran, würde überzeichnet werden (oder es wurde definiert, das auf jeden Fall zusammenzufassen ist):
    • an die bereits berechnete Linie dran hängen, graues allgemeines casing wird ggfs. durch spezielle casing für Radweg ersetzt.
  • dessen Geometrie liegt zu weit weg (evtl. Schwelle für nicht allzu weit weg liegende Geometrie, die noch zusammenzufassen ist):
    • zeichne separat
  • mal zu nahe, mal zu weit:
    • geeignete Stelle zum Wechseln... graphischer Übergang?

• Überlegung: die Berechnungen sind komplex:
  • Teilgeometrien cachen und erst wieder neu berechnen, wenn Geometrie oder tags geändert wurden?

• Frage: die Berechnungen sind komplex:
  • sollte das Grundgerüst bereits vor einem Workshop programmiert werden? Könnte zeitbudget eines Workshops sprengen. Workshop dann eher für Gestaltung im Detail und daraus nötige kleinere Änderungen an den sourcen

• Berechnung für ale Renderer ähnlich, wie programmtechnisch am effektivsten lösen?
  • Osmarender, XSLT-Variante: Geometrieänderungen nicht möglich? gestorben hiermit? Nur gecachte Geometrien, Vorverarbeitung, ...?
  • Osmarender, Perl-Variante: machbar
  • Mapnik: C++? python?
  • ...: ...?
  • gemeinsame Bibliotheken möglich mit passenden Sprach-Interfaces? Was gibt es schon im OS-Bereich?

Routen

• den Routern alles beibringen...

Planung

Offene Fragen

• Wer nimmt an dem Workshop teil?
• Welche Probleme haben die höchste Priorität?

siehe auch

• De:Bicycle, das um ähnliche Probleme kreist... Dort auch viele Links zu proposals etc., die mit Thema verwandt sind

Resultat

Es wurden ausführlich Vor- und Nachteile der oben beschriebenen Vorschläge erörtert. Als großes Problem wurde die hohe Komplexität aller Schemata gesehen, die eine gut durchdachte und einfach zu bedienende Tool-Unterstützung durch die gängigen Editoren notwendig macht. Wir kamen insgesamt zu dem Ergebnis, dass beide grundsätzliche Vorgehen (separate Ways vs. erweitertes Tagging) möglich sein sollten, da

• für viele recht einfache Situationen separate Ways als zu kompliziert angesehen werden (Knotenpunktprobblematik);
• es aber auch möglich sein muss, komplizierte Verkehrsführungen angemessen abzubilden, wofür eben mehrere Ways geeigneter sein können als nur ein Way mit sehr vielen komplexen Tags.

Die Methode, im Regelfall nur einen Way zu nehmen und ihn ausführlich mit Tags zu Versehen, wurde von der Mehrheit der Teilnehmer favorisiert (Disclaimer: so jedenfalls mein Eindruck -- DanielM 21:03, 4 December 2008 (UTC)). Gegen die OSM-Philosophie, dass letztlich jeder mappen darf wie er will und sich sinnvolle Schemata (hoffentlich) langfristig durchsetzen, wollte sich aber niemand aussprechen.

Konkret wurden folgende Verfeinerungen der existierenden Vorschläge (siehe oben) erarbeitet:

• Erweitertes Tagging von Straßen: Um unterschiedliche Sonderwegsanlagen pro Richtung abzubilden, schlägt die Arbeitsgruppe vor, die Straßenseite relativ zur Richtung des die Straße repräsentierenden Ways zu vermerken und die bekannten cycleway-Tags entsprechend zu erweitern:
  • k="right:cycleway", v="lane" und k="left:cycleway", v="track" für einen Radfahrstreifen in der Hinrichtung des Ways und einen Gehweg-geführten Radweg in der Rückrichtung; analog für die anderen Fälle. Man kann man das sicher auch für andere Sonderwege (wie die Fußwege, falls die jemand taggen will: k="right:footway", v="track") gebrauchen.
  • Abbildung zulässiger Fahrtrichtung über oneway: k="right:cycleway:oneway", v="yes|no". Da Zweirichtungsradwege per Definition absolute Ausnahmefälle sind, ist hier als Standard ein "yes" anzunehmen. Das dürfte auch für alle anderen Sonderwege außer Fußwegen gelten.
    • Dem Punkt Ausnahmefälle muss ich widersprechen. Erstens gibt es selbst in der Stadt so enge Situationen, dass auf der einen Seite nur Radweg, auf der anderen nur Fußweg ist (Kaiserstraße in Bonn und weiter in Richtung Bad-Godesberg/Südost). Zweitens ist es ausserhalb von Stadtgebieten eher die Regel als die Ausnahme, dass nur auf einer Seite Rad/Fußwege sind. Das hat sowohl Kostengründe als auch Gründe im geringen Verkehrsaufkommen. Beispiele: Bonn-Bad Godesberg <-> Meckenheim, Niederrhein.
  • Abbildung der Benutzungspflicht über k="right:cycleway:duty_of_use", v="yes|no". Auch wenn laut StVO hier ein "no" der Standard sein sollte, ist es empfehlenswert, auch ein "no" immer mit anzugeben.
  • Trennung von Geh- und Radweg bei Gehweg-geführten Radwegen: k="right:cycleway:segregated", v="yes|no". Hier existiert kein Standardfall.
    • Alternativvorschlag: Zusammenfassung mehrerer Tags in einen Tag mit eine Liste von Values, z.B. k="right|left:cycleway", v="track;duty_of_use;segregated" für den typischen getrennten Geh-/Radweg an einer Straße in Hinrichtung.

• Betreffs der Abbildung von Sonderwegen durch eigene Ways schlägt die Arbeitsgruppe folgendes Vorgehen vor:
  • Tagging des zusätzlichen Ways nicht als highway=*, sondern als lane=*: k="lane", v="cycleway|footway|bridleway|whateverway"
  • Anwendung der üblichen Tags für highways, insbesondere oneway.
  • Benennung des Ways mit dem gleichen Namen wie die Straße, zu der er gehört. Hierdurch wird die Zuordnung zru Straße gewährleistet, ohne Relationen zu benötigen.
  • Dieses Konzept könnte auch z.B. für Autobahnkreuze taugen...

Wann gehört ein Sonderweg zur Straße?

Die Gruppe ist der Meinung, dass separat eingetragene Ways für Sonderwege ungünstig sind, sofern permanent vom Sonderweg auf die Fahrbahn und umgekehrt gewechselt werden kann, z.B. wenn nur ein Parkstreifen dazwischen liegt (Radfahrstreifen und Schutzstreifen sollten also nie als eigene Ways verzeichnet werden). Dann wäre es nämlich eigentlich notwendig, sehr viele Verbindungswege zwischen Sonderweg und Fahrbahn einzuzeichnen. Daher ist es in einem solchen Fall günstiger, den Sonderweg über Tags an der Fahrbahn abzubilden. Separate Ways sind angebracht, wenn Sonderweg und Straße eindeutig getrennt sind, z.B. durch einen Grünstreifen mit Graben.

Fazit von User:Tordanik

Im Rahmen des Workshops gelang es nicht, eine definitive Empfehlung zum Tagging von Linienbündeln auszuarbeiten. Es bestand am Ende weitgehende Einigkeit unter den Teilnehmern, dass es möglich sein müsse, bei entsprechenden lokalen Gegebenheiten auch nichtparallele Linienverläufe einzuzeichnen.

Den meisten Anklang fand ein Konzept, die Linien als eigene Ways zu taggen und mit einer geeigneten Relation an die eigentliche Straße zu binden. Die Linien würden dabei mit beschreibenden Tags analog zu Straßen versehen (access etc.), als Haupt-Tag für die zusätzlichen Ways würde zur Unterscheidung von Straßen jedoch nicht highway=*, sondern etwa lane=*, mit möglicherweise eigenen Values, zum Einsatz kommen.

Disclaimer: Dies ist kein offizielles Fazit, sondern der Gesamteindruck von User:Tordanik.