Germany/Workshops/Linienbündel

Text von AndreR, erweitert von Mueck

Problematik

Status quo:

• 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 separat erfassen:

• Vorteile
  • einfacheres Taggen der Einzelwege
    • Bsp.: fahrtrichtungsabhängige tags (Radweg links, Radspur rechts, Tempolimit oder Lkw-Verbot nur stadteinwärts)
  • komplexere geometrische Zusammenhänge 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 via Einzelwege fahrzeugabhängig korrekter routen bei einfacher Erfassung der Kreuzung
    • Bsp.: Kurzzeitige Unterbrechungen oder größere Verschwenkungen von Radwegen einfacher erfassbar
• Nachteile
  • evtl. 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
  • 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.
  • Einfachere Geometrie zum Rendern
• Nachteile:
  • Freiheit wird eingeschränkt.
  • Es ist z.Z. 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.
  • Es könnte zu einer starken Zersplitterung der Wege in kleine Abschnitte kommen.
  • derzeit oft nicht gerendert

3. Die Wege auf komplexere Art als Attribut an die Straße hängen.

• 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...

• 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.

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