Danke für Deine Erläuterungen zum Landuse, aber das ist eigentlich eine andere Baustelle. Meine Frage geht weniger in Richtung korrekte Verwendung von Landuse als vielmehr Notwendigkeit von MPs. Nicht, dass ich irgend etwas gegen MPs hätte (es sei denn, es sind landuse-Monster mit 1000enden von Nodes, die quadratkilometergroße Flächen abdecken), ich habe nur bisher nicht verstanden, ob es irgend eine Mappingaufgabe gibt, die zwingend ein MP erfordert.
Es hieß ja hier im Topic bereits, dass die Riesenflächen niemand mehr bearbeiten kann und dass es wesentlich sinnvoller ist, diese in überschaubare Teilflächen zu zerlegen. Dem schließe ich mich an. Also ein Grund weniger, ein MP anzulegen.
Einfache Flächen mit “Loch” drin lassen sich ebenfalls mit areas ohne MP-Zuordnung mappen. Ich habe z.B. schon Flächen mit landuse=grass/meadow/farmland gefunden, die mitten in einer umgebenden Fläche mit landuse=residential liegen, also “Löcher” in der residential-Fläche darstellen. Das scheint kein Problem zu sein, die Flächen werden in der Hauptkarte auch korrekt gerendert. Genauso wie die bereits angeführten Flächen mit amenity=* oder leisure=* etc., die ebenfalls problemlos als area in eine umgebende landuse-area eingebettet werden können.
Wenn das aber alles mit areas ohne MP funktioniert, wozu sind MPs dann letztendlich noch erforderlich oder gar zwingend notwendig? Vielleicht sehe ich ja den Wald vor lauter Bäumen nicht mehr, aber manchmal blickt man’s halt einfach nicht. Daher fände ich es gut, wenn mir jemand hier auf die Sprünge helfen könnte.
Es funktioniert hie und da rein zufällig ohne MPs.
Wenn ich eine Insel im Wasser habe, dann ist mir und Dir und vielleicht auch dem der die Renderregeln erstellt, klar, dass da eine Insel “im” Wasser ist.
Das Selbe bei 'nem Teich im Wald, nur anders rum.
Die Daten wissen das aber nicht. Die kennen keine Teiche oder Bäume oder Inseln und wie diese miteinander konkurrieren oder was oben unten oder ausserhalb ist.
Kommt ein anderer Renderer daher und bedenkt solche Spezialfälle nicht, dann stehen - wie bspw. “in der Hauptkarte” - Bäume im Teich. Dann nimmt man eben MPs und muss nicht jedem einzelnen Renderer nachlaufen und dem erklären, dass Bäume nicht im Teich stehen.
… oder anders formuliert
man kann sich auf den Standpunkt stellen “Ein Teich im Wald muss halt nur über den Wald gerendert werden und gut ist”
mit dieser scheinbar neheliegenden Render-Regel würde eine baumbestandene Insel (und daher als Wald erfasste) in einem Teich/See aber buchstäblich “untergehen”.
abgesehen vom Rendern will man die Daten eigentlich so haben, dass das was als x getaggt ist auch x ist, und nicht dass man davon noch y und z abziehen muss, weil sie geometrisch “darüberliegen”. Multipolygone braucht man immer dann, wenn man ein Loch reinschneiden muss, oder wenn man ein Objekt mappen will, das aus mehreren Flächen besteht die voneinander getrennt sind. Oder wenn die Grenze oder ein Teil der Grenze ein bestimmtes Objekt sein soll, und nicht nur “zufällig momentan” an derselben Stelle liegen.
Man muss aber auch bedenken: landuse heißt zunächst nur Landnutzung. Im Falle von landuse=forest: Die (vorwiegende) Landnutzung ist Wald, d.h. aber nicht automatisch, dass dort überall Bäume stehen, auch wenn der Renderer das so darstellt. Ein Teich kann ein Teil des Walds sein. Ab einer gewissen Größe sollte er natürlich “allein” stehen, aber kleinere Teiche können m.E. auf dem landuse liegen.
Genauso bei Schulen: Ich versuche zwar auch, ein landuse um die Schulfläche herumzuführen. Wenn das aber nicht geht oder ich dafür extra ein MP erstellen müsste, lasse ich die Fläche einfach auf dem landuse liegen. Die Schule befindet sich nun mal in einem Gebiet mit der (vorwiegenden) Landnutzung Wohnen.
Soweit ich an den umliegenden Orten erkenne kann, ist das der Normalfall … amenities wie Kindergärten und Schulen, aber auch leisure areas wie Parks und Sportanlagen liegen überwiegen innerhalb der residential areas ohne als MP eingebunden zu sein. Dazu heisst es im Wiki:
Das liest sich für mich so, dass eine amenity auch ohne MP in die landuse-area eingebettet werden kann. Und da alle diese Flächen korrekt gerendert werden, sieht das für mich auch nicht nach einem zufälligen Ergebnis aus.
Davon abgesehen entspricht das auch der Realität, da Schulen, Kindergärten, Parkplätze und Parkanlagen normalerweise in den als Wohngebiet ausgewiesenen Flächen liegen, auch wenn diese Einrichtungen selber nicht bewohnt werden, aber das hat natürlich nichts damit zu tun, ob für die Erfassung dann areas oder MPs verwendet werden.
Aber nochmals: Ich habe kein Problem damit, für Flächen von “landuse in landuse” überschaubare MPs zu erzeugen, mir geht es nur um das Verständnis der Notwendigkeit.
OSM-Carto bedient sich dazu einer, ich würde es “Heuristik” nennen: Wenn zwei einfache Polygone (geschlossene Wege, die von den Tags her eine Fläche deklarieren) sich überschneiden, dann wird die kleinere als die “obere” angenommen, d.h. bestimmend für die Farbe, in der gemalt wird. Bei “unten” liegenden Flächen, d.h. den von der Ausdehnung her größeren, die zusätzlich mit Mustern gefüllt werden, wird dieses dann noch über die Farbe der kleineren “obere” Fläche gelegt. Keine Ahnung, wie das ausgeht, wenn drei oder vier Flächen übereinanderliegen.
Das kann gut gehen, das kann auch daneben gehen. Man kann damit z.B. eine Streuobstwiese malen, die manchen vielleicht schöner anmutet als wenn als “orchard” getaggt, obwohl sicher andere das für korrekter ansehen. Man kann damit einen Sumpf ununterscheidbar von einem getaggten “swamp” malen. Komisch sieht es aus wenn Bäume im Beton stehen (auf residential grau).
Es gibt Bestrebungen für Mehrfach-landuses. Die Verwaltung kennt ja auch Mischgebiete. Keine Ahnung, ob so was für natural etc. auch angedacht ist.
OK, ich denke, ich verstehe das Problem beim Rendern jetzt: Wenn die umliegende area mit icons gefüllt ist (wie z.B. “forest” oder “scrub”), dann wird ein darin befindliches “Loch” wie ein See oder eine Wiese zwar in der richtigen Farbe gerendert, aber die Fläche wird trotzdem mit den icons gefüllt.
Im Falle von Flächen, die in residential areas liegen, sieht man den Fehler nicht, da landuse=residential nicht mit icons gefüllt, sondern nur farblich abgesetzt ist.
Interessantes Phänomen - der Renderer erkennt zwar die Form und Art der Fläche des “Lochs”, schafft es aber nicht, die icons der übergeordneten Area wegzufiltern.
Damit ist meine Frage aber beantwortet. Danke nochmals für alle konstruktiven Hinweise dazu.
Ja, genau das ist mir gerade an einer entsprechenden Kombination von Flächen aufgefallen … war gerade noch am formulieren, als Dein Beitrag reinkam. Damit ist klar, warum in solchen Fällen MPs notwendig sind, zumindest so lange, bis die Renderer das auch ohne klar trennen können.
Letztendlich ist das ein meines Erachtens auch mittels Multipolygonen nicht lösbares Problem: Man stelle sich vor, eine Schule im Grünen mit grünem Pausenhof. Als einfache Polygone erfasst sieht es in OSM-Carto gut aus, die Heuristik trifft den Nagel auf den Kopf, drei sich überlagernde Polygone rendern korrekt: Wiese über Schule über Wiese. So weit so gut. Der “Namensraum” (landuse, natural, amenity, leisure etc. die sogenannten top-level tags) spielt da keine Rolle. Kann man mit Multipolygonen auch korrekt rendern machen, aber, der Schulhof gehört zur Schule!
Das ist kein Versehen, das ist Absicht: Die Fläche ist mehrfach definiert, OSM-Carto zeigt richtigerweise an, dass dem so ist. Kein Algorithmus der Welt kann entscheiden welche der Deklarationen gilt.
Na? Wer kommt drauf? Es gibt keinen…!!!
Die einen Angaben am Way und der einen Relation sind seamark-typische Ergänzungen… ansonsten sind es mir nicht erklärbare und unnütze Dopplungen, gepaart mit dem anscheinend immernoch vorhandenen iD-Fehler, an Stellen, wo Linien mit geschlossenen Ways verbunden sind, diese ways gesplittet und in Relationen gewandelt werden. Unabhängig davon, sollte man mit iD nie und nimmermals solche Relationen anfassen…
Sowas kommt aber auch davon, daß vielleicht gewisse Editoren (menschlich/ und Anwendungen!) sich nicht an Standards halten… anders kann ich es mir nicht erklären…
Ich werde morgen den betreffenden Bereich entrelationieren.
Sowas ist für mich zu 100% unnötig und verkompliziert den Datenbestand.
Sven
…der mal wieder im Relationsputzmodus ist…
Edit: Pah… noch eine vierte Geometrie in dem Zusammenhang gefunden… Och man…
Was “vorwiegend” ist, ist imho uninteressant wenn man das Problem vom Datenmodell her betrachtet.
Vorwiegend heisst (ich schrieb das oben schon im Ansatz), dass ein Renderer ein paar Dutzend Spezialregeln und Spezialspezialregeln implementieren muss, statt stumpf eindeutige inner-outer-MPs zu malen.
P.s. Weils immer wieder kommt: OSM-Carto und/oder osm.org ist keine Referenz für Rendering. Es ist nur EINE Referenz, wie man etwas falsch oder richtig, schön oder weniger schön machen kann.
das Rendering kann nicht als Maßstab genommen werden ob die Repräsentation der Realität in der Datenbank ok ist. Beim Rendern ist die Reihenfolge unterschiedlicher Objektklassengruppen fest vorgegeben (layers, deren Inhalt anhand von tags aus einer Datenbank geholt wird). Innerhalb eines layers (z.B. landuse und bestimmte natural Objekte) wird die Reihenfolge über layer tags und über die Flächengröße bestimmt (kleiner liegt höher). Deshalb kann carto bestimmte Sachverhalte auch nicht richtig darstellen obwohl die layertags richtig gesetzt sind.
Solches massives Relationsmapping muß für mich gerade in dicht erfassten Gebieten als veraltet gelten! Das muß immer in separate Geometrien aufgelöst werden, so es denn geht (technische Grenzen)! Sonst meißelt man ein bestimmtes Taggning auf Gedeih und Verderb fest, was dann lange Zeit keiner mehr anfasst…
Es war ein Heidenaufwand, das alles aufzudröseln… Es gab z.B. eine (!!) Relation mit landuse=residential in der alle (!!) Landuse-beteiligten Liniensegmente gesammelt wurden, ob nun simple Linien oder welche mit highway=*… Egal alles rin… Also irgendwie eine Sammelrelation für Sammelrelationen, für die keine Relation nötig ist. Ähnlich war es mit natural=wetland, landuse=grass…
Übrigens dem user geopard ist es z.B. zu verdanken, daß die Königsbrücker Heide https://www.openstreetmap.org/relation/77659 auch entsprechend entrelationiert wurde… Ok… das Ding ist immernoch groß und hat viele Elemente, Es ist aber erst mal im Rahmen der Ausdehnung des Gebietes hinreichend vereindacht…
Nur weil es ein Renderer wie erwünscht darstellt, ist es kein richtiges Mapping. Bei manchen landuse-Tags ist es vielleicht schwammiger oder weniger wichtig, ob man innere Flächen als Löcher oder als überlappend ansieht.
Aber ein ringförmiges Gebäude (Beispiel: https://www.openstreetmap.org/relation/9398337) hat nun mal einfach ein Loch. Selbst wenn in der Mitte nur eine runde Grasfläche wäre und ich die eintrage, wäre es nicht ersichtlich, dass das Gebäude ringförmig ist und nicht einfach rund mit Gras auf dem Dach. Ein MP ist hier zwingend erforderlich.
Genauso mappe ich einen L-förmigen Parkplatz nicht als Rechteck, weil über einer Ecke eine Grasfläche liegt und es so in einem Renderer trotzdem zufällig richtig aussieht.
Das würde ich so explizit nicht sagen, es hängt m.E. von dem vorgegebenen Regelwerk ab. Wenn grundsätzlich gilt, dass eine kleine Area innerhalb einer großen Area als “Loch” anzusehen ist, in dem die Attribute der großen Area keine Gültigkeit haben, dürfte es kein besonderes Problem sein, das entsprechend auszuwerten bzw. darzustellen.
Wenn das Regelwerk allerdings offen lässt, ob die kleine Area ein Loch in die größere stanzt oder aber oben drauf liegt, wie ggf. hier
dann brauche ich natürlich eine Funktion, um das kenntlich zu machen. Dann wäre die Regel also
Ohne MP liegt die kleine Area auf der großen Area, mit MP stanzt die kleine ein Loch in die große.
ein MP stanzt Löcher wenn man so will. Welche Fläche “oben” und unten liegt, definieren wir über layer tags. Ohne bzw. mit denselben layer tags sind alle Flächen in derselben Ebene, kleine wie große.
Automatisch kann man keine Löcher schneiden, sonst würden ständig Löcher geschnitten wo gar keine sein sollen
Das Regelwerk lässt die Beziehung übereinander liegender Flächen erst mal zurecht offen. Denn manchmal wäre eine kleine Fläche ein Loch in der großen, manchmal nicht.
Beispiele:
Ladenfläche in einem Einkaufszentrum: kein Loch im Gebäude
Grasfläche im Innenhof des Einkaufszentrums: Loch im Gebäude
Grasfläche auf dem Flachdach des Einkaufszentrums: kein Loch im Gebäude
Parkplatzfläche im Innenhof: Loch im Gebäude
Parkplatzfläche in der Tiefgarage: Kein Loch im Gebäude
Erraten könnte man das also nur, wenn man Regeln für alle möglichen Situationen hätte. Was spätestens dann scheitert, wenn man berücksichtigt, dass bei OSM jeder neue Tags erfinden kann.
Wohlgemerkt geht es da erst mal noch überhaupt nicht um die grafische Darstellung, sondern um die maschinenlesbare Darstellung der Realität. Ob dann der Renderer z.B. die Tiefgargage gar nicht zeigt (weil sie ja unter dem Gebäude ist), gestrichelt zeigt (damit man beides erkennt) oder über dem Gebäude zeigt (weil ihm Parkmöglichkeiten wichtiger sind als Gebäudeumrisse) ist eigentlich noch mal eine komplett andere Frage.
Finde ich einen sehr guten Vergleich. Bei der äußeren Begrenzung der Fläche kommt man deutlich weniger in Versuchung, nach einer “Ausstanzlogik” zu suchen. Man zeichnet eben die Fläche mit dem Umriss, den sie wirklich hat. Genau das sollte man auch bei der inneren Begrenzung tun.
Nochmal zur Vermeidung von Missverständnissen. Es geht mir nur um das Verständnis dafür, wann ein MP in Bezug auf “aufeinander” liegenden Areas notwendig ist und wann nicht. Dass es keine automatische “Ausstanzlogik” gibt und auch kein feststehendes Regelwerk für die Beziehung aufeinander liegender areas, ist mir soweit klar. Das wollte ich mit Beitrag #76 eigentlich darstellen.
Ich kann mit dem Editior mehrere areas übereinander legen … klein über groß und umgekehrt. Diese liegen vorerst mal alle auf derselben Ebene aufeinander. Das ist teilweise unproblematisch (amenity-area auf einer landuse-area, gebäude auf einem landuse, gebäude auf einer amenity usw.). Will ich sie räumlich über/untereinander ausrichten, benutze ich layer (tiefgarage unter einem gebäude, ein garten auf einem flachdach). Will ich, dass dass eine kleine Area innerhalb einer großen Area als “Loch” anzusehen ist, in dem die Attribute der großen Area keine Gültigkeit haben, muss ich zwangsläufig ein MP anlegen, weil ich nur dann Aussen und Innen definitiv voneinander trennen kann.
Ist das soweit korrekt und verständlich dargestellt?
Bei einem L-förmigen Parkplatz habe ich das Problem nicht, da die areas dann nicht übereinander liegen, sondern nebeneinander (mit einer teilweise gemeinsamgen Aussengrenze). Es wäre daher unsinnig, den Parkplatz rechteckig zu zeichnen und dann in einer Ecke eine Grasfläche drüberzubügeln. Theoretisch könnte ich auch das Problem der aufeinanderliegenden Flächen grundsätzlich dadurch vermeiden, dass ich die größere Fläche immmer so aufteile, dass die kleine Fläche eben nicht mehr umschlossen ist, sondern an einer durch eine Trennlinie entstandenen Außenkante liegt und auf diese Weise lauter nebeneinander liegende Flächen entstehen. Also wenn ich eine runde Wiese mit einem runden See genau in der Mitte habe, teile ich die Wiese genau mittig in 2 Teile und habe dann 3 nebeneinander liegende Flächen. Ist sicher nicht die eleganteste Lösung, aber theoretisch denkbar, oder?
Und genauso unsinnig wäre es, das ringförmige Gebäude als Kreis zu zeichnen, in der Mitte eine runde Grasfläche drüberzubügeln und hoffen, dass jemand der Gebäudeflächen berechnen möchte das richtig auseinander dividiert. Im obigen Beispiel ist es auch nicht einfach nur eine Grasfläche, es funktioniert so also eh nicht.
Nein, es ist ein ringförmiges Gebäude, nicht zwei C-förmige.
Also irgendwie eine Sammelrelation für Sammelrelationen, für die keine Relation nötig ist. Ähnlich war es mit natural=wetland, landuse=grass…
Bei der äußeren Begrenzung der Fläche kommt man deutlich weniger in Versuchung, nach einer “Ausstanzlogik” zu suchen. Man zeichnet eben die Fläche mit dem Umriss, den sie wirklich hat. Genau das sollte man auch bei der inneren Begrenzung tun.