Da ich davon ausgehe, dass Mareks Muttersprache Polnisch ist, habe ich mal den polnischen Text des proposals durch Deepl laufen lassen und erhalte folgende Übersetzung:
Die Unterschiede sind in der Übersetzung minimal, aber ich meine dennoch etwas deutlicher herauszulesen: Diese Vorgehensweise* **gilt in erster Linie **zu beachten …
*) Wobei “Vorgehensweise” sich bezieht auf: verwenden area:highway nur … wenn kein area=yes existiert
Korrekt. Und das geht meinen Englischkenntnissen zufolge auch ganz genau so aus dem für den Mapper letztendlich maßgeblichen englischen Text hervor.
Die Formulierung des englischen Textes für die von Streckenkundler interpretierte Übersetzung
müsste lauten:
This applies mostly to highway=pedestrian and highway=footway, but not in any case (oder: but not always).
jajaja… ihr habt recht und ich meine Ruhe…
Nur ist es komisch. wenn ich mir die Daten ansehe, ist es nach den von mir genannten Links etwa auch so erfasst, wie ich es sehe und lese…
Durch diese Ablenkungsdisskussion sind nun leider viel wichtigere Zeilen von mir schön untergegangen 
Kurz ich halte area=yes an den einschlägig bekannten linearen highway-Objekten die Straße oder Weg repräsentieren immer für unnötig und kann immer mit area:highway abgebildet werden, wenn eine geschlossene Fläche oder Flächenrelation vorliegt. Das schließt zu 100% service, footway und pedestrian mit ein.
Sven
Sorry, mate, et iss wie et iss un dat mut so! 
Dafür gebe ich Dir hier
uneingeschränkt Recht!
Ich persönlich habe überhaupt kein Problem mit einem sich immer weiter verfeinernden Detailmappig, auch eine Open-Geodatenbank ist doch einem permantenten Evolutionsprozess unterworfen und das Mappen von areas für alle Arten von highways ist dort, wo bereits eine entsprechende Mappingdichte erreicht ist, eine sinnvolle Weiterentwicklung. Ich sehe das nur in der Fläche (sprich: auf dem Land) noch nicht als relevant an, aber wenn es in der Provinz einen fleißigen Mapper gibt, der sein Heimatdorf damit perfektionieren will, warum nicht?
Man sollte beim Verfeinern allerdings auch immmer ein bisschen pragmatisch bleiben, damit nicht solche Kuriositäten entstehen wie landuse=flowerbed oder =depot, wo dann selbst im Wiki schon darauf hingewiesen wird, dass dafür bereits etabliertere Attributen existieren …
Ich vermute: fehlerhafte Anwendung durch den Mapper, Übersehen des entsprechenden Hinweises im Proposal oder generell nicht beachtet, dass da schon ein area=yes dran hing.
Nein, das ist mir nicht entgangen. Mir fehlte nur die zeit, darauf auch noch einzugehen.
Dem stimme ich zu. Area=yes ist m.E. nur eine Hilfestellung gewesen, den Renderer zu veranlassen, ein eigentlich als linear definiertes Objekt flächig abzubilden. Das macht durchaus auch in einigen Fällen Sinn, wäre aber, wenn man den Ansatz area:highway konsequenter verfolgen würde, obsolet werden.
Blüten treibt das area=yes in diesem Fall: Tankstelle in Rostock
Ich bin mir noch nicht ganz schlüssig, was da alles so schief gelaufen ist, aber für mich sieht es so aus, dass ja ein highway, egal ob mit oder ohne area=yes, in OSM-Carto brutal über alles drüber gerendert wird. Weil man dann aber das Tankstellendach nicht mehr sieht, wurde dieses als inner herausgestanzt. Das sieht dann zwar gerendert besser aus, datentechnisch bedeutet das aber, dass sich unterm Tankstellendach keine gepflasterte highway-service-Fläche befindet. 
Nun, diese building=roof als inner auszustanzen ist falsch…roof ist Dach und liegt ebenenmäßig immer über etwas. Hier über highway=service ;besser: area:highway=service und building=roof mit layer=+1
Sollte sich unter dem building=roof noch ein kleines “gebäudeähnliches Ding” (mir fällt nüscht besseres dazu ein) befinden, müsste nur dieses ausgeschnitten werden.
Wenn jemand sehr kleinlich ist, kann er die Bereiche, wo sich die Stützen und in der Regel zugleich die Tanksäulen befinden, ausschneiden. (“=hypermikromapping”) Ich bin zwar durchaus mal Detailversessen, aber das für mich nicht mehr sinnvoll erfassbar.
Deshalb ist das für mich so, wie ich es im Moment vorfinde, eine falsche Anwendung von type=multipolygon. Ich hab mir da mal schnell mit Bing im Hintergrund angeschaut ( übrigens schlimmer Lageversatz ) Aber das südöstliche Dach geht 1:1 in das angrenzende Gebäude über. Das ist so aber nicht erfasst. Für mich ist das ein Stück weit Mappen für den Renderer und gegen die Fehlerprüfung…
soweit erst mal… ich muß ins Bett…
Sven
Aber doch nur, wenn area:highway ein vollwertiger Ersatz für “routingfähige” Flächen, die bisher via area:yes umgesetzt wurden, wäre, oder nicht?
Dieses “Routing über Flächen” geistert schon lange durch die Köpfe… Ich bin aber der Meinung, praktikabel wird das nicht nicht funktionieren.
Auch nicht, wenn man einen echten Datentyp Polygon im OGC-Sinne hätte… Für mich sind das irgendwann zwei unterschiedliche getrennte Datenverwendungen, die man nicht vereinigen kann!
Ein praktikables Routing wird über Objekte mit area:highway genausowenig funktionieren, als über welche mit highway=* + area=yes…
Ich bin der Meinung, daß man sich von dieser fixen Idee “Routing über Flächen” verabschieden muß. Sinnvolles Routing wird nur über Linien, eigentlich Linienvektoren funktionieren… Was anderes als solche Linienvektoren sind unsere linienhaften highway-Elemente nicht!
Das Tagging mittels area:highway ist nur ein geeignetes Mittel der weiteren differentzierteren Erfassung und Darstellung der Landschaft.
Im Prinzip entkoppelt sich zwangsläufig die Flächen- von der Linienebene ein Stück weit, je mehr man es auf der großmaßstäbigen Ebene (also im Detail) betrachtet. Für mich als Geodatenverarbeiter im beruflichen Sinne ist das eine zwangsläufige Entwicklung, der man sich nicht entziehen kann. Anderenfalls muß man Tagging- und Erfasungsgrenzen einführen, was richtigerweise dann hingegen dem OSM-Gedanken widerspricht.
Je mehr man hingegen in den kleinmaßstäbigen Bereich kommt, wird die Linie (=Linienvektor) die area:highway-Elemente im übertragenen Sinne ersetzen (=zwangsläufige Generalisierung).
Beim Tagging muß man schauen, welche Eigenschaften dann für die Fläche (=merheitlich Darstellung) und für die Linie (=mehrheitlich Routing) wichtig wird.
Sven
Von der Frage zu Anfang ist man mittlerweile ja Meilen weit entfernt, trotzdem hier mein Senf:
Von Wien nach Berlin über Flächen routen, das wird wohl erst mit weitaus leistungsfähigeren Prozessoren möglich als den aktuellen. Selbst wenn die Algorithmen besser werden. Dass aber Flächen nur für schöne Renderings da sind und nicht fürs Routen, das will ich so nicht stehen lassen:
Paradebeispiel Fußrouting - ohne Flächen eigentlich nicht zu schaffen. Menschen sind keine Eisenbahn die auf Schienen (OSM Wege) fährt und von denen nicht herunter kann. Menschen queren Plätze. wo es ihnen als der kürzeste oder sonstwie liebste Weg erscheint. Detto Straßen. Will man ernsthaft alle Wege mappen, auf denen eine Fläche gequert werden? Es gibt Vorschläge zu “highway=path; path=virtual”, womit die mapper dann damit loslegen können, ohne sich über OTG Gedanken machen zu müssen…
Nicht zuletzt plädieren auch Routeranbieter für Flächen, Link dazu in einem andren Thread. Nicht zuletzt werden zB Fahrspuren nicht als eigene Wege erfasst, usw.
Nur und ausschließlich über Flächen geht auch nicht richtig… Bestes Beispiel für mich: https://forum.openstreetmap.org/viewtopic.php?pid=854387#p854387:
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=53.54538%2C10.00265%3B53.54292%2C10.00408#map=18/53.54324/10.00323&layers=N
Hier frage ich: wie soll bei diesem Detailgrad der Erfassung ein Routing über eine Fläche funktionieren, wenn keine korrespondierende Linie mit erfasst ist?
Sven
Deswegen zeichne ich in solchen Fällen zusätzlich (virtuelle) Fußwege ein, so wie bei diesem Marktplatz: https://www.openstreetmap.org/relation/8941234
Das mag man für unelegant halten, aber ich denke da ganz pragmatisch.
…genau, und in bestimmten Fällen ohnehin nötig: mal wahllos herausgegriffen: https://www.openstreetmap.org/relation/6440378
Bei mir wäre der Maktplatz noch vereinfacht: nur 1 Outer und 1 inner-Objekt…
Sven
Wenn du mich fragst: Highway=footway in Kombination mit Area=yes gehört verbannt. Hw=fw sollte nur auf Linien etwas gelten. Ab mit den Verkehrsflächen in den Area:highway Namensraum. (Hw=pedestrian wird aber schwierig…)
Praktisch sind Verkehrswege natürlich, um schnell eine Route von A nach B zu finden. Die wird es sicher in alle Ewigkeit geben müssen. Die Wegbeschreibungen aber lassen sich viel schöner ausformulieren, wenn Verkehrsflächen da sind, die es gestatten, dass von den Wegen abgewichen wird, dass Abkürzungen genommen werden, nicht jede unsinnige, rein der Konnektivität dienende Ecke abgelaufen oder um eine Verkehrsinsel herumgebogen werden muss, um die es in Wirklichkeit geradeaus vorbei geht, usw.
So schließt das fast wieder an den Aufhänger vom Thread an. Es ging da ja darum, wie man die Landuse-Lücken um die Straßen herum stopfen kann. Obwohl freilich auch Area:highway nicht bis zum Acker reicht, also wieder eine Lücke bleibt…
Tja und wir kommen zurück zu der einfachen Antwort: Es ist in OSM nicht sinnvoll, jede Lücke unbedingt schließen zu wollen.
Stimmt. Die Fläche war auch mal genau so einfach aufgebaut… und dann kam die Baustelle.
Ich lasse das jetzt erst einmal so, da die Baustelle allmählich ihrem Ende zugeht. Wenn dann klar ist, wo die neuen Flächengrenzen sind, werde ich da sowieso einiges ändern müssen. Und dann werde ich die Außengrenze wieder zu einer ununterbrochenen Linie zusammenfassen.
OT: lass mich raten… iD… nachgesehen: ja…für mich das typische Muster, wie iD outers unnötig fragmentiert…
Sven
So seh ich das mittlerweile - auch wenn es mir immer noch schwerfällt - ebenfalls.
Ich habe in meiner Gegend das Problem, dass anstatt area:highway=* häufig ein highway=* + area=yes als Tagging für den Renderer eingetragen wird. Häufig sogar mit dem falschen Wert für highway da ja nicht alle von OSM-Carto dargestellt werden. Da finde ich dann service anstatt residential oder unclassified und jede Menge Fußgängerzonen (pedestrian) anstelle von path oder footway. Da ich mich nicht immer traue, highway=* dann ganz zu löschen, kommt es zu area:highway=* + area=yes.
Die ganzen Trottoirs als Flächen mit highway=footway + area=yes hallte ich für groben Unfug und extrem Fehleranfällig. Für mich ist das eindeutig area:highway=footway und dazu sollte ein lineares Objekt mit highway=footway + footway=sidewalk eingetragen werden.
gabs denn jetzt eine zweite Meinung oder noch nicht?
Ja klar, sogar mehr als eine und ich bin für jede dankbar und ganz besonders für diese: https://forum.openstreetmap.org/viewtopic.php?pid=853827#p853827
Vorher:
Nachher:
Um eine vernünftige Kartierung von landuse=commercial, landuse=retail, landuse=industrial und landuse=residential bei mir in der Gegend werde ich mich zu einem späteren Zeitpunkt kümmern, allerdings nicht auf Gebäudebasis, da ich keinen Nutzen darin sehe.