jenes, welches Du bereits in #73 verlinkt hattest.
Man kann das Rad nicht zurückdrehen, und wenn man es könnte wäre die Mehrheit hier unzufrieden 
Etablierte tags haben in der Regel damals überhaupt keine scharfen Definitionen gehabt, die haben sie erst im Laufe der Zeit bekommen (im Sinne von “ohne Lücken unmissverständlich und klar definiert, was der tag bedeutet”, sozusagen “rechtssicher”, gibt es praktisch keine tagdefinitionen, auch heute nicht), durch das Niederschreiben und sukzessive Überarbeiten und Diskutieren (und natürlich auch durch die Benutzung). Dadurch hat man versucht, den Bedeutungswandel zu dokumentieren, sofern er stattgefunden hat. “Micromapping” ist gar nicht definiert, wenn man anfängt, jede einzelne Hausnummer und alle Gebäude zu mappen, dann ist das aus Sicht von OSM in den Anfangszeiten sicherlich schon “Micromapping”. “Waterway=riverbank für einen 30m breiten Flussarm oder einen 50m breiten Fluss, das ist doch übertrieben, der tag ist nur für große Flüsse.” Das hat mir vor vielen Jahren mal jemand geschrieben. Was Dir heute wie Micromapping vorkommt ist morgen vermutlich schon üblich (je nachdem, ich bestreite nicht, dass ich öfters mal Details finde wo ich auch denke, das hätte ich überhaupt nicht gemappt, und das wird vermutlich auch zukünftig kaum jemand mappen).
schau nochmal richtig nach:
area:highway mit area=yes https://overpass-turbo.eu/s/1fE1
area:highway ohne area=yes https://overpass-turbo.eu/s/1fE3
Hervorhebung von mir.
Sven
@streckenkundler: entweder übersetzt mein deepl missverständlich oder ich verstehe nicht , was Du mir damit sagen willst.
Ich verstehe den absatz so: area:highway nicht für echte Plätze (Don’t use area:highway=* for plazas and similiar features.)
Es steht area:highway mit area=yes ist incorrekt. Es soll ausschießlich area:highway genutzt werden, wenn ein linienhafter highway ohne area existiert. Letzter Satz: Das gilt auch meistens aber nicht exklusiv für highway=pedestrian und highway=footway.
Mit anderen Worten für den letzten Satz: in bestimmten Fällen kann bei area:highway=pedestrian und area:highway=footway auch ein area=yes gesetzt werden.
Wenn du dir meine beiden Overpass-Links anschaust und die ohne area=yes nimmst, haben an der östlichen Grenze des Kartenausschnitten die Wege im Park kein area=yes. Diese repräsentieren die als Flächen abgebildeten linearen Wege.
Die andere mit area=yes scheint für mich weitere Fußgängerbereiche z.B. an Kreuzungen und so mit einzuschließen, die nicht ausschließlich eine Linie repräsentieren. Es wird also mit und ohne area=yes angewendet, während man bei anderen wie z.B. area:highway=tertiary oder residential man area=yes nicht findet.
Soweit ich es überblicke, ist der verlinkte Ausschnitt auf den ersten Blick hinreichend nach dem Street_Area-Proposal erfasst.
Leider ist User [Marek_kleciak](marek | OpenStreetMap kleciak) hier im Forum kaum oder nicht mehr aktiv. Er hatte das ganze ausgeheckt. Da findet sich im Forum auch was dazu: z.B.: https://forum.openstreetmap.org/viewtopic.php?id=18265
Sven
Das gibt der Satz nicht her und würde auch im direkten Widerspruch zum vorausgehenden Text stehen. Das “nicht ausschließlich” bezieht sich darauf, dass es auch Fälle jenseits von highway=pedestrian bzw. highway=footway geben kann, wo eine Fläche mit area=yes versehen wurde und sich die Verwendung von area:highway=* somit verbietet.
+1
+1
Ich übersetze das mal so: “Dies gilt vor allem, aber nicht ausschließlich für highway=pedestrian und highway=footway.”
Und da widerspreche ich Dir. Für mich liest sich das eher so, dass vorallem bei pedestrian und footway aufgepasst werden muss, dass area:highway nur dann zugefügt wird, wenn kein area=yes vorhanden ist. Aber auch bei anderen hw kann es vorkommen, dass da schon ein area=yes steht (nach meiner Erfahrung kommt das bei hw=service durchaus öfter vor) und dann kein area:highway gesetzt werden soll.
Warum hat dann diese kleine Fläche ein area=yes und die große angrenzende Fläche wiederum nicht?
Ich kann da ehrlich gesagt kein Muster erkennen. Oder kannst Du mir den Unterschied zwischen https://www.openstreetmap.org/relation/7970776#map=17/52.39917/16.89847 und https://www.openstreetmap.org/relation/7534302#map=17/52.39924/16.89982 begründen?
Es verwässert aber die Bedeutung der tags und vergrößert das Chaos. Ein einfaches barrier=kerb hätte es auch getan.
Mein 80er-Jahre-DDR-Nachmittags-Schulenglisch ist zwar ziemlich schlecht, aber ich bleibe bei meiner Meinung. Ungeachtet dessen aber bin ich persönlich der Meinung, daß generell (=stets!) bei Anwendung von area:highway ein area=yes am highway=* dann nicht nötig ist (=immer!). Mit area:highway angewendet ausschließlich auf Flächen und Flächenrelationen (wie wir das in OSM definieren) bewegt man sich in einem eignenen Namensraum. Es sollte dann eher highway=* mit area=yes generell überprüft werden.
Die Grundproblematik ganz tief unten ist hier wieder, daß wir keinen echten Datentyp Polygon haben… denn dann… ok, ich stichele schon wieder… 
… ich müsste das visualisiert sehen, aber wenn die Definitionen nicht gut oder komplett sind, kann sowas bei rauskommen. Da ist aber wieder das, was ich auch schrieb… es fehlt ein Referenz-Rendering und auch langfristige eine Disskussion der Probleme. Wir müssen schließlich auch beachten, daß das besagten Proposal inaktiv ist, daher derzeit keine Anpassung und Ergänzung stattfindet. Es ist aber das einzige, welches zu der Thematik erstmal verwendbare Lösungen bietet. Daher müssen wir hier auch tolerant sein.
Sven
PS. Ich tippe im Moment vom Tablett… Sorry, wenn das Quoting etwas falsch ist.
PS1: Ich hoffe, Quotes und Links passen nun.
wenn es sich um eine Fläche handelt, dann ist area=yes nie falsch, sondern höchstens überflüssig / redundant. Wieso man auf einem Platz kein area:highway verwenden soll erschließt sich mir auch nicht. Für den Platz als Objekt verwendet man mittlerweile sowieso place=square
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