DE:Proposed features/Street area
Hier wird ein Vorschlag für die Notation von Straßenflächen beschrieben. Autor: Marek Strassenburg-Kleciak
Note: Die deutsche Fassung ist veraltet, es wird um den Abgleich mit der englischen Version gebeten!
Eine Straße soll, ähnlich wie der Fluß, doppelt repräsentiert werden:
- Durch die Mittelachse (bisheriges Vorgehen)
- Durch die Fläche (Tags sollte man gemeinsam erfinden)
Dadurch können Straßen in sehr hohen Zoomstufen richtig dargestellt werden, genauso wie komplexe Kreuzungsbereiche sowie Parkbuchten.
Bisherige vorgehensweise wird also ergänzt.
Achtung: Das vorgehen kann nur für Bereiche wo Luftbilder in "very high, ultra high, super hight" Auflösung vorhanden sind.
Straßen als Mittelachsen
Die Straßen werden in OpenStreetMap als Mittelachsen der Verkehrsflächen gezeichnet:
Pict.0.
Die allgemeine Vorgehensweise bei der Berechnung der Straßenflächen ist die Darstellung der Straßenmittelachsen mit einer Breite die entsprechend der Straßenkategorie in verschiedenen Renderer unterschiedlich angenommen wird.
Da Straßenbreiten varieeren, kann eine solche globale Annahme unmöglich exakt die Realität abbilden:
Der Straßenraum kann in hoheren Zoomstufen nicht richtig in seiner Ausprägung gerendert werden.
Das entstehende Bild der Straße entspricht nicht der tatsächlichen Straßenfläche, von allen in komplexen Kreuzungsbereichen.
Zusätzlich erschwerend für eine exakte Berechnung der Straßenflächen sind die Generalisierungvorschrifen durch die bestimmte Straßenabschnitte nicht gezeichnet werden, da sie aus der Sicht der simplen Routingvorschriften als überflüssig bzw. sogar störend gelten:
Pict.1. ( vergleiche mit Pict.0. )
Tagging mit width=* <mittlere Straßenbreite in Meter> erlaubt eine relativ gute Darstellung außerhalb komplexer Kreuzungsbereiche und kann mit diesem Konzept kombiniert werden.
Straßenflächen
Der Proposal schlägt die Erfassung der Straßen als Flächen vor, wobei einzelne Abschnitte zwischen den Kreuzungen als einzelne Flächen gezeichnet werden und die Kreuzungen separat:
Diesem Schema folgend, können die Straßen auch in verschiedene Nutzungszonen aufgeteilt werden wodurch die Renderer zusätzliche Darstellungsmöglichkeiten bekommen.
Pict.2.
Flächentypen
hellgrau | blaugrau | grün | magenta | dunkelgrau | violett |
---|---|---|---|---|---|
Straßenfläche befahrbar | Kreuzungsfläche befahrbar | Trennfläche nicht befahrbar (Grünstreifen) | Straßenfläche nicht befahrbar | Sonderfläche befahrbar | Sonderfläche (Taxi, Bus usw) |
Tagging
Tag | Nutzugg | Typ | Wert | Beschreibung |
---|---|---|---|---|
area:highway |
erforderlich | value | Befahrbare Straßenfläche | |
junction |
erforderlich | yes | Straßenkreuzungsfläche. Beginnt mit der durchgezogenen Linie (Stopp Zeichen), bzw Außenkante Zebra Streifen. Falls Beides nicht vorhanden sehe Skizze unten. | |
area:highway |
erforderlich | traffic_island | Nicht befahrbare Straßenfläche | |
area:highway:permissive |
erforderlich | yes | Straßenfläche nur für Busse und Taxis. | |
amenity=* | wünschenswert | parking_space | Parkfläche. | |
name=* | erforderlich | Text | Name der Straße identisch mit dem Namen der Straßenmittelachse. | |
name2=* | erforderlich | Text | Name der Straße identisch mit dem Namen der Straßenmittelachse. (1) |
(1) - Zur Verwendung im Falle der Kreuzungen die ein Teil zweier bzw. mehr Straßen sind. Analogisch name3, name4 usw. im Falle der Kreuzungen die viele Straßen verbinden. Durch diese Option wird der Renderer in der Lage sein den Straßenverlauf in den Navigationssystemen richtig darzustellen.
Key | Description | value |
---|---|---|
Area | Zeichnet Straßenflächen für Zoomstufen ab 14 | Street |
Area | Zeichnet Brückenflächen für Zoomstufen ab 14 | Bridge |
Area | Zeichnet Tunnelflächen für Zoomstufen ab 14 | Tunnel |
Layer | Entscheidet über die Reihenfolge der übereinander liegenden Flächen für Zoomstufen ab 14. Je Höher die Zahl, umso höher (relativ zueinander) liegt eine Fläche | -5 bis +5 |
Straßen- und Brückenflächen werden als Areas nach dem gezeigten Muster gezeichnet. Natürlich ist dies nur dort möglich, wo excellentes Luftbild vorliegt.
Logische Verbindung
Erforderliche Restriktionen
- Benachbarte Flächen MÜSSEN gemeinsame Punkte haben
- Die Knotenpunkte K der Mittelachsen (auf dem Bild rot) MÜSSEN gemeinsame Punkte mit den Punkten der Areas haben. Tagging Vorschlag crossing=yes
- Die beiden nächstgelegenen Punkte links und rechts von K auf dem Umriss von Area MÜSSEN auf der Straßenausenkante liegen.
Frage: Warum müssen die gemeinsame Punkte K für Area und Straße gezeichnet werden? Man könnte im rechten Winkel die zu zeichnende Linie ermitteln?
Antwort: Es gibt des Öfteren Kreuzungen, an denen die Haltelinien nicht im rechten Winkel zum Straßenverlauf sind, daher ist es die einzige Möglichkeit topologisch korrektes Bild zu rendern.
Ziel: Richtiges Rendern der Straßenaußenkanten. Die Technik wird weiter im Text beschrieben.
Rendering
In Verbindung mit der bekannten Anzahl der Spuren, sowie Information über die Art der Umrandung der Areas ( entsprechende Tags müssen her, z.B.: durchgezogen, gestrichelt usw.) kann ein realitätsnahes Bild des Straßenraumes gerendert werden. Die Voraussetzung dafür ist das entsprechende Taggen u.A. von dem Punkt K. Dieser Tag hebt die Taggingwerte der Außenkanten der Area von dem Punkt K-1 bis K+1 und ersetzt diese durch einen bzw. zwei Tags die an den Punkt K angehängt werden.
Linientypen für Rendering
- none - Keine Trennlinie.
- solid_line - Durchgezogene Linie
- double_line - Doppellinie
- solid_dashed_line - Linie
- dashed_line - linie gestrichelt
- giveway_line -Linie bestehend aus Dreiecken (Halt+ Vorfahrt achten)
Tagging von dem Knotenpunkt K
Tag | Nutzung | Typ | Wert | Beschreibung |
---|---|---|---|---|
crossing:end=* | erforderlich | yes | Punkt, wo die Kreuzugsfläche endet/beginnt. | |
left=* | wünschenswert | none, solid_line, double_line, dashed_line, giveway_line | Die Art der Trennlinie vor der Kreuzungsfläche. Links von der Straßenmittelachse in Richtung Kreuzung. | |
right=* | wünschenswert | none, solid_line, double_line, dashed_line, giveway_line | Die Art der Trennlinie vor der Kreuzungsfläche. Rechts von der Straßenmittelachse in Richtung Kreuzung. |
Hier folgen einfache Beispiele: ....
crossing = yes
left = <value> *
right = <value> *
* values : none, solid_line, double_line, dashed_line
Kein Tag für left= und right= bedeutet für Rendering: links und rechts von K wird für Rendering die gleiche Farbe verwendet wie die der Straßenoberfläche.
Aufteilung der area:highway in Teilbereiche
Die Voraussetzung für realitätsnahes Rendern ist die Aufteilung des Umrißpolygons der area:highway. Dies wird erreicht durch das entsprechende Taggen von dem jeweiligen Punkt Kn. Dieser Tag hebt die Taggingwerte der Außenkanten der Area von dem Punkt Kn -1 bis Kn+1, und ersetzt diese durch einen bzw. zwei Tags die an den Punkt Kn angehängt werden.
Beispiel:
K1:
crossing: yes
left:solid_line
right:solid_line
K2:
crossing: yes
left:none
right:solid_line
Kein Tag für left: und right: bzw. Wert: none bedeutet, links und rechts von K wird für Rendering die gleiche Farbe verwendet wie die der Straßenoberfläche. Also keine Umrandung der Straße in diesem Abschnitt.
Falls an die highway:(tertiary, secondary, primary, residential..usw) zwischen dem Punkt K1 und K2 die Anzahl der Spuren bekannt ist, kann sie für Rendering unter Verwendung der Außenkanten der area:highway verwendet werden. Hier ein Beispiel mit 6 Fahrspuren:
Grüne Linien sind lediglich Konstruktionslinien die das Konstruktionsprinzip veranschaulichen und werden auf der gerenderten Strasse nicht sichtbar!
Möglicher Rendering der Straßenflächen unter Berücksichtigung anderer Elemente der Karte
Achtung, die Bilder B,C,D sind nicht auf der Grundlage der Rohdaten (A) gerendert, sondern sind eine mögliche Visialisierung der Areas mit entsprechendem Tagging. Das Rohdaten - Bild zeigt zudem ein Negativbeispiel für die schlechte Interpretation der Vektorverläufe dar. Die einzelnen Highways sollten sich bei einer derartigen Kreuzung nicht sternförmig treffen.
B. Example rendering, surfaces only.
C. Example rendering, additionally parking, treess.
D. Example rendering, additionally pedestrian crossing.
Zu C: Das Ergebnis auf dem Bild basiert auf der Annahme, dass ein footway auf der street Fläche als Zebra Streifen mit einer festen Breite gerendert wird -
falls die Breite des Weges nicht vorhanden ist.
Option. Fuss und Radwege
Die Technik der Bearbeitung der Straßenflächen als Area verbunden mit zusätzlicher Beschreibung der Punkte auf dem Umring des Polygons area:highway könnte zudem optional eine realitätsnahe Darstellung der Fuss und Fahrradwege erlauben, falls diese selbst nicht als areas erfasst werden, sondern lediglich als zusatzliche Taggingwerte der Straße.
Hängt man dort zum Beispiel auf der einen Seite:
1. Fahhradweg, und an der anderen
1. Gehweg
2. Fahrradweg
wird das Ergebnis jeweils nur in den Abschnitten des Umrißpolygons zwischen den Punkten K-1, K+1 gerendert:
Setzt man die Punkte auf dem Umriss "außer Betrieb" indem man sie explicite als zum Beispiel: cycleway:no landuse:grass taggt,(auf der Zeichnung sind diese beiden Punkte rot), sähe das Ergebnis so aus.
Sonstiges
Abwärtskompatibilität
Die hochgenaue Darstellung der Straßenfläche ist erforderlich aus Sicht zukünftiger Anwendungen und damit verbundener Innovation in OpenStreetMap, die eine höhere Zoomstufe benötigen. Für Mapnik und andere Renderer in ihrer jetztigen Form können sie jedoch an einigen Stellen zum Problem werden: Zwar wird die Berechnung der Straße als Fläche beim Rendern ganz einfach nicht berücksichtigt, die Verbindungen einzelner Fahrspuren, die für exakte Darstellung notwendig sind, verwischen unter Umständen in niedrigeren Zoomstufen das klare, generalisierte Bild. Siehe Skizze E. unten.
A. Starke Generalisierung, für Kalkulation einfacher Streckenberechnungen geeignet.
B. Berücksichtigung physikalisch getrennter Fahrstreifen.
C. Berücksichtigung rechtzeitiger Abbiegemanöver nach RECHTS.
D. Berücksichtigung eines rechtzeitigen Abbiegemanövers nach LINKS.
E. Berücksichtigung aller rechtzeitigen Abbiegemanöver nach LINKS.
Möglichkeiten von dem erweiterten Rendering: Zebrastreifen
Ist Zebrastreifen ein Weg senkrecht zu der Straßenmittelachse (ein Standardfall also), dann muss der highway=footway nicht gezeichnet werden. Der Rendering geschieht automatisch wie unten:
A. Pp - Der Punkt wird getaggt als highway=crossing.
B. Punkte 1 und 2. verbinden eine Gerade die senkrecht zur Straßenmittelachse ist. Die Linie highway=footway ist überflüssig.
C. Ergebnis nach dem Rendering.
Wenn der Fussweg nicht senkrecht zur Staßenmittelachse ist bzw. wenn er (in seltenen Fällen) seine Richtung ändert:
D. Polylinie 1-2 ist getaggt als highway=footway sowie footway=crossing.
E. Mögliches Ergebnis nach dem Rendering.
F & Q
Werte für area:highway
- Frage: Ich wäre für das mappen von area:highway über andere Flächen z.B. landuse=residential. Oder sollen solche Flächen entlang der "area" geteilt werden? Wie soll das geregelt werden? Vielleicht liese sich hier auch das Problem "Straßenbegleitgrün" als area (Fläche in der Verantwortung der Straßenmeisterei / Autobahnmeisterei / Gemeinde) mit ergänzen.
Antwort:
- Frage: Welche area:highway Werte haben bei Kreuzungen Vorrang, wenn mehrere unterschiedliche Arten aufeinandertreffen, zum Beispiel wenn sich eine secondary und eine residential road kreuzen? Die Area für residential dann splitten? Oder ein eigenes value für Kreuzungen einführen?
Antwort: Es soll darüber diskutiert werden, ob die Darstellungsart in der Straßen als Flächen gezeichnet werden, überhaupt derartige Attributierung braucht, da die logische Darstellungsebene in der die Strassen als Mittelachsen gezeichnet werden, bereits diese Information beinhaltet. Die Attributtierung mit Werten: Secondary, Residential usw. wurde eingeführt, um Straßen richtig zeichnen zu können. Eine Flächendarstellung wie hier vorgeschlagen, benötigt diese Zusatzinformation prinzipiell nicht, da sie für die höchsten Zoomstufen gedacht ist.
- Frage: Sollen alle Kreuzungsbereiche als separate Flächen gezeichnet werden? Für eine Kreuzung vom Typ X kann ich es nachvollziehen, für eine T Kreuzung hingegen nicht.
Antwort: In kurz: Ja. In langer Form: Für den Rendering der Elemente in der höchster Zoomstufe wir aller Wahrscheinlichkeit nach nicht mehr die Berechnung der Bitmaps, sondern eine Echtzeitberechnug der Vektorflächen verwendet werden ( HTML 5). Es kann durchaus passieren, dass an eine sehr lange Hauptstraße (Sehr viele Punkte im Umriß) Seitenstraßen anschließen und wir wollen an der Verbindung vom Typ T ( Seitenstraße an Haupstraße) die exakte Darstellung dieser Kreuzung sehen. Die Berechnung wird schneller erfolgen, wenn auch die Hauptstraße in Segmente unterteilt ist.
- Frage: Gibt es andere Gründe für die Erfassung der Straßen als Flächen.
Antwort: Ja, es ist die 3D Darstellung. Man kann mit der Area Straße das dreidimensionale Geländemodell verbessern, indem man sie für´s Glätten des 3D Modells verwendet.