Das mit der primären Erfassung der Flächendaten hast du falsch verstanden. Es geht nur darum, dass man das, was am Weg sinnvoll erfassbar ist, auch dort erfasst und auch zum Rendering nutzt. Prinzipell sind dies erstmal über die Weglänge konstante Breiten von Fahrbahn oder Fahrspuren. Möglicherweise auch noch abweichende Breiten am Weganfang und -ende ggf. mit einer Längenangabe des Übergangs und einer Art des Übergangs wie zum Beispiel linear oder als Spline.
Eine Zerlegung in infinitesimal kleine Wegabschnitte habe ich dabei weder angedacht, noch ist sie sinnvoll.
Für manche Straßen erreicht man damit schon eine sehr passende Flächenbeschreibung und für andere, wie deine Ortsstraße, nur eine sehr grobe Näherung.
Selbst wenn wir nur Straßentyp abhängige Standardbreiten ansetzen, haben wir damit aber schon global betrachtet eine deutlich bessere Flächenerfassung als wenn man 1% als area:highway gezeichnet hat und für den Rest kleine Flächendaten hat.
Wenn du deine Ortstraße detailliert erfassen möchtest, spricht nichts dagegen, dies als Ausnahme zu erfassen, indem du den Fahrbahnrand komplett zeichnest.
Es gibt z.B. Städte mit vielen Straßenbäumen wie z.B. Hamburg , da wird das Zeichnen von area:highway zum Problem. Und in tropischen Regionen helfen dagegen nichteinmal mehr Winter-Luftbilder, falls man denn überhaupt solche in hinreichender Qualität zur Verfügung hat.
Tunnel sind ein ähnliches problem.
In der Serpentinenkurve bietet sich an den rechten Fahrbahnrand separat zu zeichen und damit eine Ausnahme von der Standardbreite zu beschreiben.
Der Schlauch kann aber natürlich auch asymetrisch anhand des placement und lanes tags berechnet werden, und eine Verfeinerung durch Zeichnen des Fahrbahnrands ist natürlich jederzeit möglich. Es ist jedoch auch niemand genötigt z.B für zig Autobahnkilometer konstanter Breite Flächen zu zeichen. Wenn man letztere nicht mit sehr hoher Präzision zeichnet, ergeben sie ohnehin eine schlechtere Flächenbeschreibung als die Tags am Weg.
Dies könnte auch durchaus ein interessanter Ansatz sein. Man sollte dazu aber zunächst Standardbreiten für Fahrweg und Fahrspuren im Weg erfassen und dann nur Abweichungen in den Nodes. Man braucht auch eine gute Editorunterstützung. Diese kann wie folgt aussehen: In hohen Zoomstufen werden die berechneten Fahrspur- und Fahrbahnränder als Linien gerendert. Auch Radweg- und Fußwegränder können enthalten sein. Die dazu berechneten Stützpunkte dieser Ränder müssen vom User graphisch seitlich verschiebbar und damit an das Luftbild anpassbar sein. Aus der verschobenen Position hat der Editor geeignete Tags für die Datenbank-Nodes zu berechnen.
Auf niedrigeren Zoomstufen und in nicht unterstützenden Editoren sollten die entsprechend getaggten Nodes weder verschiebbar noch löschbar sein.
Problematisch sind Bereiche mit großen Geometriefehlern des OSM-Weges, an deren Vermeidung noch zu arbeiten wäre.
“Jede Erkenntnis die man auf rein theoretischen Wege erlangt, ist, was Realität anbelangt, inhaltsleer.” … In diesem Sinne rate ich allen Verfechtern der “Erfassung von Straßen- und Flussbreiten an der Linie” zum praktischen Selbstversuch. Bitte rausgehen und vor Ort in ausreichender Quantität und Qualität die Breite erheben.
Noch ein Hinweis: Bitte bringt euch bei dem Unterfangen nicht in (Lebens-) Gefahr.
Man muss das mit dem Messen nicht zu genau nehmen, toc-rox. Das kann man notfalls auch auf den Satellitenbildern machen - so wird es ja bei Gebäuden auch gehandhabt mkt hinreichender Genauigkeit.
Ich stimme auch slhh zu (und so war es auch gemeint), dass man diese Breitenangaben an Knoten nur dort macht, wo es sinnvoll ist. Ansonsten kann und sollte man auf die schon existierenden Instrumente zurückgreifen, die da Fahrstreifenanzahl und -(Standard)breite sowie Straßenbreite am way sind. Bei diesen Spezialfällen kann man schon mal vor Ort oder in der Karte messen, und ersteres muss gar nicht lebensgefährlich sein. Mit einem guten Laser-Distanzmesser geht das recht gefahrlos (habe ich schon ausprobiert).
Ich bin auch dafür, die Straßen (in erster Linie die Kreuzungen) zusätzlich als Fläche zu erfassen.
Ich betrachte das Thema in erster Linie aus Nutzer-Sicht, als Nutzer von Navigations-Software.
Was erwarte ich von meinem Navi (egal, in welcher Form)?
Vor allem an komplizierten Kreuzungen ist für mich der genaue Verlauf der Fahrspuren interessant. Das könnte man, wenn denn die Daten vorliegen, mit einem kurzen Blick auf die unterlegte Karte sehen, bevor man in die Kreuzung einfährt. So etwas zu erklären, ist wohl nicht möglich.
Das im Moment verwendete Modell mit Abbiegespuren als lanes und der “heiligen” Maßgabe, ja nur die Straßen so zu erfassen, wie sie als “Hardware” (Bordstein zu Bordstein) vorliegen, wird dem in keiner Weise gerecht.
Bei einer “normalen” zweistreifigen Straße klappt das sehr gut, aber da ist es wohl dem Fahrer egal. Gerade wenn sich Straßen mit mehreren Fahrstreifen und getrennten Fahrbahnen kreuzen, versagt das Modell. Muss ich voreinander nach links Abbiegen; muss ich eine Sperrfläche oder eine Verkehrsinsel umfahren? Das gleichen Problem tritt auf, wenn zwei Einmündungen versetzt aufeinander zu stoßen.
Und: Es gibt meines Wissens nach kein etabliertes Modell für das tagging von Sperrflächen. Diese haben aber oft einen wesentlichen Einfluss auf die Straßengeometrie. Was nützt mir die Angabe, dass die Straße an einer Stelle 13m breit ist und zwei Spuren hat, wenn in der Mitte eine Sperrfläche von 6 m vorhanden ist, die die zwei Linksabbiegespuren aus Gegenrichtung entschärfen soll? Vielleicht gibt es ja auch auf der rechten Seite eine Sperrfläche, weil da noch irgendwann eine Rechtsabiegespur auf eine im Moment nur geplante Straße eröffnet wird?
Ich würde gerne ein paar Beispiele hier als Bilder einfügen, betreibe aber keinen Webserver, auf dem ich die Bilder bereitstellen kann und die Forensoftware unterstützt ja kein Hochladen von Bildern.
Mach einfach mal einen Rechtsklick auf ein paar Bilder und gucke Dir deren Adresse an (Grafik anheigen oder Grafikinfo). Du wirst feststellen, dass die Leute verschiedene Portale nutzen. Da kannst Du Dir dann eins aussuchen
Wir sollten endlich mal den Mut aufbringen, uns von solchem Mappen für unzureichende Anwendungen zu verabschieden, dass uns die Geometrieinformation kaputtmacht.
Wenn wir die Fahrspuren mit Ihren Übergangsmöglichkeiten nach dem Lanes-Schema erfassen, sollte dieser Weg auch bis dorthin führen, wo dies korrekt ist. Eine anschließende abzweigende Abbiegefahrbahn müßte dann geometrisch korrekt an gleicher Stelle mit leichtem seitlichen Versatz beginnen, wäre also zunächst unverbunden. Mit komplexen geometrischen Auswertungen wäre zwar automatisch feststellbar, dass hier doch eine Straßenverbindung vorliegt, jedoch wäre dies natürlich sehr praxisfern. Stattdessen können wir die logische Querverbindung durch einen quer zum Straßenverlauf liegenden virtuellen Weg darstellen, den wir z.B. highway=crossbar taggen.
Router, die ohne Spurunterstützung arbeiten, können den highway=crossbar in der Datenvorverarbeitung eliminieren, indem sie dessen Nodes zu einem einzigen Node zusammenfassen.
Eventuell können wir vereinfachend auch den virtuellen Querweg mit der Abbiegefahrbahn zu einem rechtwinklig abgeknickten Weg vereinen und mittes Tag highway:start=crossbar kennzeichnen, dass das erste Segment des Weges die crossbar-Funktion hat und somit nur eine virtuelle Verbindung darstellt. Diese vereinfachte Variante hätte zudem wohl den Vorteil, vorhandene Applikationen weniger zu beeinträchtigen. Da Sie das Tag nicht kennen und somit missachten würden, sehen sie nur einen kleinen Geometriefehler.
Leider ist Placement Proposal wieder mal ein halbgares unzureichend diskutiertes Proposal, dass es es nie zum RFC oder gar Voting geschafft hat, aber dennoch angewindet wird. Es adressiert zwar einige sinnvolle Dinge, jedoch meines Erachtens doch sehr suboptimal und das Tag placement=transition ist da wohl der schlimmste Fall.
Nehmen wir mal eine mit placement=transition getaggte Kante an. Diese representiert ein Stück realen Straßenverlauf und Rechtwinkling dazu einen Querversatz der Wegpositionierung. Zusammen bilden diese ein rechtwinkliges Dreieck, dessen Hypotenuse die Kante in der Datenbank ist.
Das Problem ist jetzt, dass eine Hypothenuse nicht hinreichend ist, um ein rechtwinkliges Dreieck eindeutig zu definieren und Angaben zum Querversatz fehlen.
Es passen damit beliebig viele Dreiecke von dem Grenzfall, dass der Querversatz gegen 0 geht, zu dem Grenzfall, dass die Länge des repräsentierten realen Straßenstücks gegen 0 geht und die Kante somit reinen Querversatz repräsentiert.
Letzterer Grenzfall ist mein obiger Anwendungsfall für highway=crossbar. Man mag placement=transition dort als anwendbar ansehen, jedoch fehlt ihm die Information, dass dieser spezielle Grenzfall vorliegt. Da kein realer Straßenverlauf mehr repräsentiert wird, werden auch keine Straßeneigenschaften am Crossbar benötigt.
PS: Man wird in vielen Fällen auch mit mit placement=transistion einen schönrechnen können, wenn man die Lane-Konnektivität ermittelt hat und darüben dann ggf. auch einen nötigen Querversatz bestimmen kann. Die Bestimmung der Lane-Konnektivität ist bei OSM ohnehin noch ein Problem und placement=transition sorgt auch noch dafür, dass Geometrieinformationen fehlen, die dabei eventuell helfen könnten. Eine solide Basis für die Lageerfassung von Fahrspuren ergibt sich so jedenfalls nicht.
