DE:Proposed features/Street area

From OpenStreetMap Wiki
Jump to: navigation, search
Verfügbare Sprachen — Proposed features/Street area
· Afrikaans · Alemannisch · aragonés · asturianu · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · Bân-lâm-gú · Basa Jawa · Baso Minangkabau · bosanski · brezhoneg · català · čeština · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · latviešu · Lëtzebuergesch · lietuvių · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · português do Brasil · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · беларуская · български · қазақша · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · मराठी · हिन्दी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 吴语 · 粵語 · 中文(繁體)‎ · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް

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.

Strassen als Mittelachsen

Die Straßen werden in OpenStreetMap als Mittelachsen der Verkehrsflächen gezeichnet:

StreetsGeneralisedVectorLevel.JPG

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:

StreetsGeneralisedLevel.JPG


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:

StreetsLogicalLevel.JPG

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:


MarekStreetsAsFaces.jpg

Diesem Schema folgend, können die Straßen auch in verschiedene Nutzungszonen aufgeteilt werden wodurch die Renderer zusätzliche Darstellungsmöglichkeiten bekommen.

Streetsasfaceswithpointslegend.jpg

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 Area value Befahrbare Straßenfläche
junction erforderlich Area 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 Area traffic_island Nicht befahrbare Straßenfläche
area:highway:permissive erforderlich Area yes Straßenfläche nur für Busse und Taxis.
amenity=* wünschenswert Area 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

Streetsasfacesconnection.jpg


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.

Streetrenderingwithoutlines.jpg


Linientypen für Rendering

  • none - Keine Trennlinie.
  • solid_line - Durchgezogene Linie

MarekLineSolid.jpg

  • double_line - Doppellinie

MarekLineDoubleSolid.jpg

  • solid_dashed_line - Linie

MarekLineSolidDashed.jpg

  • dashed_line - linie gestrichelt

MarekLineDashed.jpg

  • giveway_line -Linie bestehend aus Dreiecken (Halt+ Vorfahrt achten)

MarekLineGiveWay.jpg

Tagging von dem Knotenpunkt K

Tag Nutzung Typ Wert Beschreibung
crossing:end=* erforderlich Node yes Punkt, wo die Kreuzugsfläche endet/beginnt.
left=* wünschenswert Node 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 Node 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.

Kpoints1.jpg

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.


Kpoints2.jpg

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:

Kpoints3.jpg

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.

MarekGeneralizationCrossingwithSurfaces0.jpg A. Raw data.

MarekGeneralizationCrossingwithSurfaces1.jpg B. Example rendering, surfaces only.

MarekGeneralizationCrossingwithSurfaces2.jpg C. Example rendering, additionally parking, treess.

MarekGeneralizationCrossingwithSurfaces3.jpg D. Example rendering, additionally pedestrian crossing.

MarekGeneralizationCrossingwithSurfacesNow.jpgE. Rendering jetzt.


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:


Kpoints4.jpg

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.

Kpoints5.jpg

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.

MarekGeneralizationCrossing0.jpg A. Starke Generalisierung, für Kalkulation einfacher Streckenberechnungen geeignet.

MarekGeneralizationCrossing1.jpg B. Berücksichtigung physikalisch getrennter Fahrstreifen.

MarekGeneralizationCrossing2.jpg C. Berücksichtigung rechtzeitiger Abbiegemanöver nach RECHTS.

MarekGeneralizationCrossing3.jpg D. Berücksichtigung eines rechtzeitigen Abbiegemanövers nach LINKS.

MarekGeneralizationCrossing4.jpg 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:


MarekPedestrianCrossingCalculation1.jpg A. Pp - Der Punkt wird getaggt als highway=crossing.

MarekPedestrianCrossingCalculation2.jpg B. Punkte 1 und 2. verbinden eine Gerade die senkrecht zur Straßenmittelachse ist. Die Linie highway=footway ist überflüssig.

MarekPedestrianCrossingCalculation3.jpg C. Ergebnis nach dem Rendering.


Wenn der Fussweg nicht senkrecht zur Staßenmittelachse ist bzw. wenn er (in seltenen Fällen) seine Richtung ändert:


MarekPedestrianCrossingCalculation4.jpg D. Polylinie 1-2 ist getaggt als highway=footway sowie footway=crossing.

MarekPedestrianCrossingCalculation5.jpg E. Mögliches Ergebnis nach dem Rendering.

F & Q

Werte für area:highway

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

Platzhalter , Baustelle

Marek0onlyMiddleAxis.jpg

Marek1outlineStreet.jpg

Marek2dividingOutlineStreet.jpg

Marek3LanesDirections.jpg

Marek4LanesDirection.jpg

Marek5lanesDirectionFinal.jpg