Straßen (auch) als Flächen mappen...

en-Wiki, Thema Autobahnanschlüsse:

This node should be positioned as the last point before the splay at which it is still possible to make a smooth turn.

Also: Den Trennungsnode an den letztmöglichen Punkt vor der richtungsmäßigen Trennung setzen, aber so, dass noch eine elegante Kurve möglich ist (also kein harter Winkel sein muss).

–ks

Bei mir sähe das Teil so aus (auch noch nicht hochgeladen):

Den Rechtsabbiegerampen noch ein placement=left_of:1 verpasst, dann stimmt sogar die Lage.

–ks

Das finde ich auch gut, dass ganze Thema darf eines nämlich auf keinen Fall - vorschnell und übereilt angegangen werden.
Deswegen ändere ich ja auch nichts daran sondern bin der Meinung das wir hier mal diskutieren sollten… Und wie du und ich ja schon geschrieben haben… Technisch ist daran gar nichts auszusetzen. topologisch absolut ok gemappt…

Nur… Nach meiner Erwartungshaltung die ich an eine Karte habe, wird hier die Realität auf der Karte nicht so abgebildet wie sie ist (und das ist immer mein persönlicher Anspruch an die von mir erfassten Daten)

Als Vergleich hier mal Google https://www.google.de/maps/@49.5115861,8.5566614,19z und Falk https://www.falk.de/maps?gs=falkOriginal&gp=49.511863,8.557190&gz=16

Bei Google sieht die Kreuzung zwar aus meiner Sicht erstmal realitätsgetreuer aus, da sie nicht diesen komischen 5-Stern in der Mitte hat, aber der Kniff ist, das Google einfach schon bei Sperrflächen anfängt zu trennen, nicht erst bei der baulichen Trennung (imho. finde ich dass sogar in vielen Fällen besser)…

Und Falk hat die meiner Meinung beste Ansicht, wenn ich eine reine Straßenkarte haben möchte… Einfach eine Kreuzung zwischen 2 Straßen… Ohne gedöns… Aber halt auch nur gut wenn ich einen groben überblick über den Verlauf der Straßen will… Wenn ich wissen will, wo die Fußgänger hin können, bringt mir sowas nichts.

Und die OSM ist eben nicht mehr nur eine einfache Straßenkarte (so wie die Falk-Karte) :slight_smile: sondern mittlerweile eher wie ein CAD-Abbild einer Satellitenansicht, was aus meiner Sicht auch sehr gut so ist und überhaupt erst den echten Endusermehrwert ausmacht (Die Daten interessieren ja nur uns Interessierte). Und die ganze Arbeit die in den Polygonlinen steckt, war/ist auch gut und wichtig - eben weil man damit supertoll Routen berechnen kann. Nur im Moment haben die Renderer gar keine Chance es anders zu machen - Die Width-Tags auszulesen halte ich für sehr schwierig und Falsch, da sie nur eine Kenngröße darstellen. Ich jedenfalls habe noch keine Straße entdeckt, bei der sich die Breitenangabe an jedem Knick und auf Ganzer länge immer überall korrekt ändert, das könnte auch niemand erfassen, bzw. wäre es viel mehr Aufwand das zu erfassen, als diese Informationen z.B. aus Area-Flächen automatisch zu errechnen! Straßen sind eben in der Realität keine “plattgewälzten” symmetrischen Linien, sondern sie sind Asymmetrisch und mal rechts ein bisschen bauchig, mal links einen Meter Breiter, damit man besser abbiegen kann… In Kurven mal ein bisschen breiter, damit man besser um die Kurve kommt (Serpentinen)… Das kann man alles mit Linien-Tags gar nicht darstellen.

Mein Parade-Beispiel ist immer ein Fluss. Einen Fluss mappen wir grundsätzlich als Area. Wenn jetzt ein Fluss in den anderen fließt und im Delta herummeandert, mappen wir für gewöhnlich jeden einzelnen Meander (schreibt man das so? :slight_smile: ) als Fläche. Die Flussmitten jedoch haben ihre Polyline… wie z.B. hier beim Rhein http://www.openstreetmap.org/way/83015625#map=9/51.3436/6.6093… Die Koexistenz zwischen Wasserfläche und “Linie” ist hier irgendwie völlig normal und keiner Hinterfragt es groß… Aber bei Straßen schon?! das Verstehe ich dann irgendwie nicht so ganz.

Angenommen die Kreuzung wäre mit Areas gemappt… und die Renderer würden auf das System irgendwann wechslen. Dann sähe die Kreuzung aus wie sie in der Realität ist. Die Spuren könnten dann dort getrennt werden, wo es in der Realität sinn macht. So wie es jetzt abgebildet ist würde man - wenn man sich exakt an die Linien hält in jeder Kurve eine durchgezogene Linie überfahren und bekommt Probleme mit der StVo…, wenn die Standart-Ansicht aber Flächen rendert, sind die Daten nicht mehr zwangsläufig an solche Dogmen gebunden wie “Wir trennen nur wo baulich getrennt ist” … sondern dann kann man davon - wo es sinn macht auch abweichen. Z.B. um nicht über durchgezogene Linien geroutet zu werden… Die Kartenansicht - bleibt dann - von so etwas unberührt, da sie auf den Areas beruht.

Analog zum Flussmodell … Wenn Rhein jetzt irgendwo unter Wasser ne Sandbank hätte, dann müsste man die “Fahrspur” des Schiffes auch entsprechend anpassen und um die Sandbank herumleiten… Die Ansicht des Flusses sollte sich dabei aber nicht ändern, da der von oben Betrachtet immer noch das gleiche Bild zeigt.

Ich glaube dass sich highways-Area und Polylinien ergänzen und nicht gegeneinander stehen sollten!

@slhh

Deinen Beitrag fand ich sehr gut… vielleicht taucht Marek ja auch noch in diesem Thread auf… Aber das ist konstruktives herangehen an die Sache… Deinen Ansatz hingegen halte ich für falsch, da ich ganz massiv gegen

bin. Warum? Weil es eine wahnsinnige Arbeit bedeutet die alles bisher dagewesen bei weitem übersteigt… In welchem Abstand soll man die Straßenbreiten den Messen gehen, in 50m Stücken, in 5m Stücken…? Wenn ich alleine an die Ortsstraße vor meiner Haustüre denke, ergibt sich bestimmt auf 2km Länge 300-400 mal eine Breitenänderung im Bereich von 1-2m. Wer soll das auf diese Weise erfassen? Und wenn ich die Daten aus den Satellitendaten ermessen muss, dann habe ich die Area deutlich schneller abgezeichnet und kann einen OSM-Mathematiker dransetzen, der mir dann die Breite an jeder Stelle aus dem Polygon errechnet.

Das dürfte sehr merkwürdige Ergebnisse bei asymmetrischen Straßenverläufen ergeben, da der Schlauch ja immer von der idealisierten Mitte aus betrachtet wird. Wenn die Straße jetzt aber nur Rechts breiter ist (z.B. in der Kurve einer Serpentine) wird die Straße aber nach deiner Methode überall gleich breiter. Und das dürfte dann sehr merkwürdig aussehen.

Dieser Kritikpunkt geht ins Leere. Die Linien sind ja niemals nicht zum exakten Nachfahren gedacht, sondern sind Abstraktionen möglicher Fahrtrouten. Jede Linie – nehmen wir mal die von Osten kommende – steht dabei für die gesamte Straße mit sämtlichen Spuren. Der Punkt, an dem die Rechtsabbiegerampe im Datenmodell vom durchgehenden Way abzweigt, ist mitnichten der Punkt, an dem sich der Fahrer von der Straßenmitte wegbewegt, sondern ist der Punkt, an dem die Rechtsabbiegespur (die ja im lanes:=* und turn:lanes=* des von Osten kommenden Ways enthalten ist!) in eine eigene Fahrbahn übergeht. Da muss niemand eine durchgezogene Linie überfahren, denn auf der Rechtsabbiegespur ist er ja schon. Nur muss dieser Punkt zwangsläufig (da auf der Linie liegend, die die gesamte Straße repräsentiert) in der Straßenmitte liegen und nicht am rechten Rand, wo er einklich hingehört. Das in eine tatsächlich abzufahrende Linie „umzurechnen“ wäre Sache eines Routers, was er sogar lagegenau leisten kann, wenn er lanes:=* und width:lanes=* hat.

–ks

Hm. Hier kommt man mit dem Anworten ja gar nicht hinterher …

Ich wollte gerade mitteilen, dass ich den Ansatz von slhh in #11, den firstAid in #20 ablehnt, ziemlich richtig finde, weil er genau meiner Denke entspricht. Auf der anderen Seite kann ich die Gedanken von Dir, firstAid, zu großen Teilen nachvollziehen und unterstützen. Das Problem “wie oft messe ich dann” bezüglich der Straßenbreiten sehe ich übrigens genauso wenig wie bei der Frage, wann ich einen neuen Punkt setze, um eine Kurve gut abzubilden: Man macht es einfach so oft, wie es notwendig ist. Bei bestimmten Straßenverläufen ist es häufiger, bei anderen weniger häufig. Das sehe ich als kein Problem an, zumal, wenn man im Editor das gerenderte Ergebnis direkt sehen kann (wie bei Fahrspuren), sich also sukzessive an die ideale Knotenanzahl herantasten kann.

Die Geschichte mit dem Fluss … ja, da könnte man sicher Parallelen ziehen. Allerdings gibt es auch ein paar mehr Straßen als Flüsse … Naja, und ich pendele auch immer im Spannungsfeld zwischen “vielen geometrisch richtigen Daten” und “wenigen komprimierten Daten”, die aber die gleiche Information beinhalten, hin und her. Beides hat Vor- und Nachteile, die leider oft auch geschmacks- oder anwendungsabhängig sind.

Ein gutes Beispiel sind die Fahrspuren. Leider gibt es ja dieses o.g. Dogma mit der baulichen Trennung. Hier würde ich mich so weit aus dem Fenster lehnen und behaupten, dass es eigentlich überholt ist. Es entstand halt zu einem Zeitpunkt, als man es noch zur sauberen Datendarstellung brauchte und gar keine Möglichkeit hatte, so detailier zu mappen wie heute. Ich habe jedenfalls bei Kreuzungen und dergleichen immer wieder Schwierigkeiten damit und würde mir wünschen, dass man – wenn nötig (und nur dann) – von dieser Regel abweichen könnte. Das würde im Zweifel darauf hinauslaufen, dass man jeden Fahrstreifen einer Kreuzun mit einem eigenen Way mappt. Ich sehe vor meinem geistigen Auge, wie manchen die Haare zu Berge stehen :wink: Aber was soll´s – falls es gewichtige Argumente gibt, das Dogma aufrecht zu erhalten, dann bleibt es. Ansonsten muss man gucken, wie man neue Lösungen schafft.

Achso, nur noch ein Punkt zum Beispiel oben (OT): Ampeln machen auch immer Spaß. Wenn man welche setzt wie z.B. die in den Abbiegespuren, dann muss man sie auch so taggen, dass sie nur für den Weg gilt, für den sie eben gilt. Denn sonst bekommt man beim Abbiegen plötzlich eine Ampel vorgesetzt, die gar nicht für einen selbst relevant ist. Zum Beispiel. Habe mir die Daten nicht angeguckt, weiß also nicht, ob es da so oder so ist.

Übrigens … nicht falsch verstehen, aber wir schreiben hier manchmal so locker, flockig von Dingen, die abgestimmt werden müssten und dass man das dann mal in eine Wiki schreibt undso … nur sollten wir im Hinterkopf behalten, dass wir hier nicht der Nabel der OSM-Welt sind und es auch noch andere User gibt auf dieser Welt :wink: DIe Proposal- und Abstimmungsprozesse hatte ich ja schon mal angesprochen letztens.

Mit der üblichen Frage: Woher weiß der Router, dass die Fahrspur beliebig gewechselt werden kann? Momentan gehen ja die Router bei parallel unverbunden verlaufenden Ways davon aus, dass das nicht möglich ist – wo heute Fahrspuren einzeln gemappt sind, geht der Router, der seinen Nutzer auf einer Geradeausspur ortet, obwohl rechts abgebogen werden muss, davon aus, dass die Abzweigung verpasst wurde, und wird bereits eine Umleitung suchen. Was wieder den Nutzer verwirrt: Nanu, eben sollte ich noch rechts abbiegen, jetzt auf einmal geradeaus?

Das ließe sich beispielsweise über Fahrbahnrelationen lösen, in denen man die „wechselfähigen“, zu einer Fahrbahn gehörenden Spuren zusammenpackt. Prinzipiell habe ich nichts dagegen, weil Geometrien sich dann viel schöner abbilden lassen und vor allem die furchtbaren turn-Relationen dann nicht mehr gebraucht werden, um Fahrspuren von einem Way zum anderen fortzusetzen.

–ks

Ja, Du hast Recht, eine Abkehr von dieser Regel würde eine Menge Arbeit bedeuten, ggf. auch Änderungsaufwand an bestehendem Mapping. Daher glaube ich nicht, dass es von heute auf morgen passiert. Aber man sollte sich Gedanken darüber machen, und das am besten im globalen Rahmen – ist ein bisschen nervig, aber so ist es nun mal.

Kleiner Einwurf meinerseits: Aktuell werden Straßen ihrem Typ nach mit einer zoomabhängigen normierten Breite gezeichnet. Ich denke, dass das zunächst sinnvoll ist als Abstraktion, um ein einfaches Ablesen der Karte zu ermöglichen. Im Prinzip machen das alle gedruckten Karten so. Das Problem ist dann wohl hier, dass Abstraktion (Lesbarkeit / Nützlichkeit) und Realität (Sattelitbild / Micromapping) aufeinander treffen, wobei ich die gut ablesbare Abstraktion als höherwertig ansehe als die Reale Straßenbreite. Hierbei spielen für mich die “Lücken” eine Vermittlerrolle zwischen Abstraktion und Realität, was an sich gut ist. Man kann die Lücken/Flächen vielleicht als landuse=highway taggen und das Seitengrün als landuse=meadow/rock/… und die abstrakte Straße dann on-top.

Ich denke die reale Straßenbreite zu rendern ist kein guter Weg, denke ich (zumindest nicht in DE). Das könnte zu Verwechslungen zwischen den Klassen (primary, secondary, …) führen, nur weil eine Gemeinde mehr oder weniger Geld für Asphalt hatte.

Als Zwischenlösung, die sowohl der Abstraktion als auch der Realität dient, könnte man die Anzahl der lanes auswerten und programmatisch die gerenderte Breite normiert anpassen. Das dürfte die Übersicht nicht gefährden.

Ja das ist genau die Sichtweise die absolut nicht mit meiner Übereinstimmt.

  1. Eine Linie repräsentiert eine Straße! (sonst würde sie nicht mit dem Atribut “highway” getaggt werden)
  2. Diese Spezielle Linie (Highway) ist in diesem Fall mit dem Tag “Verbindungsweg” getaggt, was bedeutet - eine Straße die einen Verbindungsweg repräsentiert.
  3. Eine Linie (zwischen zwei Punkten) hat immer einen Anfang und eine Ende
  4. Die Punkte repräsentieren somit zwangsläufig den Beginn und das Ende des “Verbindungswegs”

Angenommen deine Sichtweise ist richtig - kann hier aber kein Verbindungsweg beginnen, da die Verbindung von einer durchgezogenen Linie unterbrochen wird und somit nie und nimmer ein Weg repräsentieren kann.

Was wir also in der Datenbank haben, ist etwas anderes als den Weg - du sagst es ja selbst, es ist mitnichten der Punkt an dem man auf die Verbindungsweg wechseln kann. Insofern ist der Kritikpunkt schon berechtigt, da dann nämlich genau die Linie - die mir sagt - wo ich wechseln kann in der Datenbank ja fehlt und stattdessen eine andere Linie die vorgibt - der Verbindungsweg (so heißt die Linie schließlich) zu sein, der aber defacto auf der Hälfte unterbrochen wird (also das Gegenteil einer Verbindung ist).

Und hier die Arbeit auf die Renderer abzustellen ist ehrlich gesagt mehr als fragwürdig - woher soll ein Renderer wissen wo genau eine durchfahrt möglich ist und wo nicht. Die Aufgabe eines Renderers ist ja nicht die OSM-Datenbank zu ergänzen sondern die Daten innerhalb der Datenbank möglichst brauchbar abzubilden!

Zudem: Wenn es so wäre, wie du es sagst, dürften wir die Linie gar nicht mit “Verbindungsweg” taggen, denn der Zweck dieses Wegtyps ist es ja die “Verbindung” zwischen zwei anderen Dingen herzustellen…

Das musst du mir also nochmal genauer erklären, wieso meine Kritik hier ins Leere geht…

Noch eine generelle Anmerkung…

Meiner Meinung nach braucht es eigentlich nicht mal zwingend ein Proposal zum Mapping von den von mir gewünschten Flächen. Imho. müssen diese Flächen auch keinen “Highway”-Bezug (was aber vielleicht ganz gut wäre) Aber wir haben ja - rein für die Fläche schon den Tag “Surface” der bisher überwiegend als sekundärer Tag genutzt wird, aber bei dem eine Flächennutzung ja ebenfalls vorgesehen ist.

http://wiki.openstreetmap.org/wiki/Key:surface

Das wäre z.B. auch eine Lösung für den “Übergang”… Und wenn das Flächenddeckend zum Einsatz käme (gewisse Eigendynamik vorausgesetzt) würden die Renderer vieleicht auch irgendwann Surface-Tags rendern

Aus der eigentlichen Diskussion halte ich mich hier mal raus - das macht meiner Meinung erst dann wieder Sinn, wenn Alle bereit sind, die vermeintlichen Notwendigkeiten des Renderings nicht in die Diskussion einfließen zu lassen, sondern das Ganze aus der Perspektive des Mappers zu betrachten und wie dieser am effizientesten und robustesten die Realität dokumentieren kann.

Ich möchte aber mit der immer wieder gebrachten urbanen Legende von der Fluss-Analogie aufräumen:

Das ist falsch. Flüsse werden in OSM als ways mit waterway=river erfasst. Alle Attribute des Flusses, Namen und was auch immer noch, gehen an diese ways. Sie sind die Erfassung des Flusses in OSM, ohne diese fehlt der Fluss. Die riverbank-Polygone hingegen erfassen die wasserbedeckte Fläche. Es gibt in OSM keine festen Regeln, ob und wann diese erfasst werden muss. Sie ist folglich optional. Jeder Mapper kann frei entscheiden, wo er diese erfassen möchte und wo nicht. De facto ist es so, dass für Flüsse, die nicht wenigstens etwa 10m breit sind (und das sind mehr als 3/4 aller Fluss-Kilometer der Welt), so dass ihr riverbank-Polygon spätestens ab etwa z16 im Standardstil breiter als die Linienbreite von waterway=river dargestellt wird, nur sehr selten riverbank-Polygone erfasst werden.

Das entscheidendere ist jedoch, dass dies ein Mapper-zentriertes Erfassungs-Konzept ist. Für jeden Karten-Gestalter, der nicht die trivial-Darstellung verwenden möchte (alle Wasser-bezogenen Linien-und Flächen-Elemente in einheitlicher Farbe) ist das Ganze im Grunde ein Albtraum. Es gibt da auch eine Menge Verbesserungs-Potential, insbesondere würde eine verbreitete Erfassung der durchschnittlichen Flussbreite (width=*) den Nutzwert der Daten mit recht wenig Aufwand massiv steigern. Wegen fehlender Verwendung solcher Informationen durch die Datennutzer sind die Mapper hier jedoch nicht sonderlich aktiv.

Also etwas vorsichtig sein mit der Idee ich möchte Straßen wie Flüsse erfassen - wegen die Geister die ich rief und so. Oder möchte irgendwer ernsthaft, dass in allen OSM-Karten Straßen so dargestellt werden wie Flüsse?

Hallo, ich hatte ursprünglich eine sehr lange Antwort erfasst… aber vielleicht hast du mich einfach auch nur falsch verstanden, oder ich habe es nicht gut genug ausgedrückt…

Mir ging es bei dem Beispiel um die Coexistenz zwischen der realitätsbezogenen Flächenabbildung und der abstrakteren Ways-Abbildung… Erst beides zusammen ergibt die bestmögliche Abbildung des realen Flusses… Und bei Flüssen ist das halt jedem klar!.. DAS war meine Aussage - nicht, dass ich alle Straßen zu Flüssen machen will. :wink: Flüsse sind nun mal hier das Paradebeispiel, da sie sowohl als Way als auch als Area erfasst sind… Und das friedlich und ergänzend nebeneinander. Aber das Thema will ich jetzt gar nicht ausweiten…

Nur einen kleinen Hinweis:

genau das machst du beim Fluss-Thema aber auch nicht

Und ich finde es nicht mal sonderlich schlimm, wenn man “auch” daran denkt was man später aus den Daten machen kann… Denn ich sehe mich insbesondere auch als Servicedienstleister gegenüber dem Enduser… Wir sind Teil einer Informationskette und wir müssen alle zusammenarbeiten

Mapper->OSM->Renderer/Datendarsteller->Enduser

Bei uns fängt aber alles an…

Ein Überschwemmungsforscher will vielleicht die OSM-Daten mal nutzen um potentielle Überschwemmungsszenarien zu berechnen… dafür braucht er zwingend die Riverbank-Informationen. Eine abstrakte Flusslinie bringt ihm nix, wenn er nicht weiß wie “Scharfkantig” die Begrenzungen sind oder ob das Wasser vielleicht in einer weichen Kurve fließt… Das ist alles Sachen die wir als Datenerfasser gar nicht im Auge haben können - Wenn wir aber Informationen möglichst umfassend erfassen, kann der Überschwemmungsforscher was damit anfangen.

Und bei Straßen ist es nicht anders… Vielleicht interessiert es irgendwann mal ein OpenAICar, wie weit es auf einer Straße nach Rechts ausweichen kann und noch auf Asphaltierter Fläche bleibt - und würde gerne die Erstabschätzung anhand von OSM-Daten vornehmen. Wer von uns weiß schon, was die Zukunft bringt…

edith wollte noch was los werden :slight_smile: :
Ich finde, das viele sich hier immer sehr stark anmaßen zu bestimmen wie die OSM-Daten zu Erfassung zu verwenden zu sind…
Um mal am Flussbeispiel zu bleiben - was genau ist dein Problem damit, wenn irgendwo auf der Welt jemand einen Fluss “nur” als Riverbank erfassen würde? Es tut doch niemandem weh - und es ist besser als wenn der Fluss nicht erfasst wäre… “Du” kannst ja dann gezielt nach solchen Areas suchen und diese um die Ways komplettieren… Ich sehe nicht was in der Vorgehensweise “Falsch” sein sollte. Im Gegenteil - genau das ist meiner Meinung nach der Kern der OSM.

An dem Beispiel sollte man beachten, dass es ein “Overlay” zu OSM ist. Gedacht war ja die area:highway-Flächen unter den Way zu rendern:

http://wiki.openstreetmap.org/wiki/File:OSM-area-highway.jpg

Wenn ein Renderer nur waterway=* darstellen will kann er waterway=riverbank für eine Liniendarstellung ausblenden.

Wenn ein Renderer nur highway=* darstellen will kann er area:highway ausblenden.

Stimmt. Aber habt ihr schon bemerkt, das OsmAnd die Straßenflächen auch darstellt und tatsächlich unter dem Way? Als reine weiße Strasse.
Aber dann auch die Segmentlinien, was mich etwas stört. Habe jetzt kein Bildbeispiel.

Einige Anmerkungen zur Kartendarstellung:
In niedrigen Zoomstufen werden Straßen absichtlich (deutlich) breiter dargestellt als sie in Wirklichkeit sind. An diesem Sachverhalt soll sich auch gar nichts ändern. Somit sind die Straßenflächen erst für die hohen Zoomstufen, so ab Level 17, interessant. Denn hier transportiert die Flächendarstellung mehr Informationen. Wichtig wäre es aber, dass sich beide Darstellungsformen hinsichtlich Straßenfarbe und Straßenbegrenzung ähnlich sehen.

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?