Ja, wobei dieses schöne Prinzip ja leider durch die Taggingvariante natural=water + water=river verwässert wurde.
Meine Sichtweise ist die: Der Way repräsentiert die Straße in ihrer gesamten Breite. Der Node, an dem die Abbiegerampe abzweigt, repräsentiert die “Höhe”, auf der sich die Fahrbahnen trennen - aber nicht zwischen rechts und links, sondern nur zwischen vorn und hinten. Seine Position gibt den Input für “jetzt rechts abbiegen”. Aber nicht für “von hier aus schräg rüberfahren”. Ich stelle mir das so vor, dass der Rechtsabbiegeway auf der ganzen Breite vom Hauptway abzweigt. Dann müssen keine durchgezogenen Linien überfahren werden.
Nein, ich argumentiere hier, dass die Tatsache, dass die Erfassung von Flüssen für die differenzierte Datennutzung ein Albtraum ist, belegt, dass das bei den Flüssen ein Mapper-zentriertes Erfassungs-Konzept ist. Ich beschreibe hier den Ist-Zustand der Gewässer-Erfassung, während Du dich in einem Analogie-Argument zur Begründung deiner Ideen für den Soll-Zustand bei den Straßen versuchst (was wie erläutert nicht funktioniert).
Ich hab auch garnicht argumentiert, dass das schlimm ist - es wird nur kaum gemacht und darüber ist hoffentlich auch niemand unglücklich.
Ich betone noch mal meine zwei Ratschläge:
- die vermeintlichen Notwendigkeiten des Renderings bei der Diskussion, wie etwas erfasst werden soll, ignorieren. Die Betonung liegt hier auf vermeintlichen - denn es sind im Allgemeinen nur Bequemlichkeiten.
- auf das Analogie-Argument Straßen sind wie Flüsse zu verzichten - das stimmt einfach in keinerlei Hinsicht.
Hast Du das schon mal versucht?
erst seit 2014 mit 16:3 Stimmen
wobei ich diese Taggingvariante wesentlich besser finde, da so eine Unterscheidung der Gewässerfläche nach Fluß, Kanal, Gewässeraltlauf, ect. möglich ist, eine Sache, die ich hier im Spreewald zu schätzen gelernt habe.
…das wird aber hier OT.
Man kommt aber irgendwann nicht mehr darum herum, Straßen als Flächen zu erfassen… Das habe ich 2013 bereits geschrieben:
https://forum.openstreetmap.org/viewtopic.php?pid=329131#p329131
Ich Zitiere mich mal selbst:
Ich gehe sogar soweit zu sagen, daß die Taggingweise, mit der man Rad- und Fußwegeeigenschaften an der Straße erfasst wird, dann aufgegeben werden muß, wenn man area:highway erfasst. Dann funktioniert auch die tactile_paving - Erfassung und kerb=*
Sven
PS: welchen Abbildungsmaßstab haben wir den eigentlich bei der höchsten Zoomstufe Z19?
Danke… bei Z19 also ca. 1:1000…
Sven
Für den 52-ten Breitengrad gilt dies:
Zoom Denominator
0 1 : 344205412
1 1 : 172102706
2 1 : 86051353
3 1 : 43025676
4 1 : 21512838
5 1 : 10756419
6 1 : 5378210
7 1 : 2689105
8 1 : 1344552
9 1 : 672276
10 1 : 336138
11 1 : 168069
12 1 : 84035
13 1 : 42017
14 1 : 21009
15 1 : 10504
16 1 : 5252
17 1 : 2626
18 1 : 1313
19 1 : 657
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.
Gruß Protoxenus
mit deinem OSM-Account (anmelden):
http://wiki.openstreetmap.org/wiki/Special:Upload
da es sich um OSM Beiträge handelt sind sie hier richtig - und einfach zu verlinken.
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.
Das hab ich jetzt nicht alles gerafft 
placement=transition existiert bereits zu genau diesem Zweck.
–ks
+1
Wie bitte?
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.