Hallo Michael
Wenn du dich in deiner Argumentation auf simple features berufst, dann solltest du uns ‘Unwissenden’ einen Link zur Definition der “simple features” liefern, damit wir eine Möglichkeit haben einen ähnlichen Kenntnisstand wie du zu erreichen.
JM2C
Edbert (EvanE)
Wenn ich ihn richtig verstanden hab, wollte er das über feste Regeln machen. Da ist dann geregelt, dass ein Spielplatz zum Wohngebiet dazu gehört, ein Feld aber nicht.
Wie aber bereits angesprochen, hat das dann zur Folge, dass es einen festen Tag-Katalog geben muss, was landuse anbelangt. Was aber nicht möglich ist. Wird ein neuer Wert “erfunden” führt das sofort zu Fehlern, weil eine Fläche eben nicht übermalt wird. Ebenso ist man gezwungen, alle Werte dieses Katalogs auszuwerten.
Das wird dann eine Übersicht mit 100ten Spalten und ebenso vielen Zeilen? Also eine Spalte landuse=residential mit Zeilen wie natural=scrub nein, leisure=playground ja, landuse=commercial nein, leisure=park ja…und das für jeden Tag der eine Fläche sein kann, dann je eine Zeile und eine Spalte
Ich kann mir nicht vorstellen, dass er das so gemeint hat. Damit könnte ich ja meine Hauswand tapezieren. Schauen wir mal 
man könnte aber auch eine Hirachie anlegen.
Also ganz unten drüber und noch darüber. Das wäre dann im Prinzip nichts anderes als das konsequente verwenden des Layers, was auch heute schon möglich sein sollte. Allerdings nicht ist. Linienförmige Strukturen wie Straßen liegen manchmal über Flächen. Selbst wenn sie einen höheren Layer haben.
also eine Wiese kann in einem Wald sein, aber ein Wald kann auch auf einer Wiese stehen. Was ist dann oben und unten in der Hierachie…
Ich fasse mal zu #19-#22 zusammen und spare mir die Zitate.
Die von mir zitierte Definition der Polygone entspricht den simple features und weicht wie vieles sonst von der nich allgemein gebräuchlichen OSM-Definition ab. (Irgendwo habe ich hier im Forum mal von babylonischer Sprachverwirrung geredet…).
Spielplätze (leisure=) im Acker sind nicht zwingend residential zuzuordnen. Es gibt auch welche die liegen mitten im Wald. Mir geht es hier um überwiegende Nutzungen, die exklusive Nutzungen beinhalten können und ein Verfahren welches uns in diesen Fällen MP’s ersparen kann. Der genannte Acker, den der Bauer nicht zur Bebauung verkaufen will liegt möglicherweise mitten in einem residential-Gebiet, was dessen überwiegende Nutzung auch nicht verändert.
Wie ich oben schon schrieb: mir hat folgende Präsentation zum Verständnis der simple features und der GIS-Welt außerhalb von OSM sehr geholfen
http://www.slidefinder.net/g/geoinformation_iii_vorlesung/5859813
Ich verlange keineswegs, dass wir uns nun streng an den simple features halten (siehe #18)
Leider hat mich aighes falsch verstanden. da die überwiegenden MP-Probleme in landuse-bereichen auftreten, möchte ich dort die Beschränkung auf Gebiete mit überwiegender Nutzung, in denen Flächen mit exklusiver Nutzung enthalten sind oder sein können, die sich aber durch einen besonderen Schlüssel auswertbar unterscheiden. So weit ich weiß, gibt es mit Spielplätzen keine Probleme bei der Darstellung, da diese als leisure sowieso über landuse gerendert werden. Wie das bei leisure=playground in leisure=park ist, müsste ich mal schauen. So wie ich das sehe haben die Renderer alle ein Schema, nach dem sie Wege und Flächen auf identischem layer übereinanderzeichnen (building u.a. immer oben)
…schon wieder der Wald als schlechtestes Beispiel für ein Gebiet mit überwiegender Nutzung. Deshalb habe ich für mich angedacht (aber noch nicht zu schreiben gewagt), landuse=forest durch landuse=forestry zu ersetzen, damit die überwiegende Nutzung klarer wird. forest könnte dann für exklusive Nutzung Verwendung finden.
Wenn das dann so ist, hätten wir für Wald in Wiese oder Wiese in Wald als zwei Werte des Schlüssels für exklusive Nutzung leider den bekannten Konflikt und kämen dann nicht um ein MP herum.
Lass bloß die Layer aus dem Spiel 
Es geht hier nicht nur darum, dass eine Karte schön aussieht, sondern bspw. auch darum, dass man den Flächeninhalt einer Flächennutzung berechnen können möchte. Da kann man nicht sinnvoll mit Layern (oder ähnlichem) arbeiten.
@Michael:
Nicht der Wald ist böse… Ist ja nur ein Bsp. Das gleiche geht auch mit Wiese und See. Ist jetzt die Wiese böse und wir brauchen einen Tag für “ist Wiese, kann aber noch was anderes drin sein”? Das für jeden Flächen-Tag wird monströs. Über die Relation ist das ganze eindeutig, über das (Zusatz-)Tag hab ich nur die Info, dass das hier ein Wohngebiet ist und das was anderes drin ist, aber ich weiß nicht, ob es ein Wald, eine Wiese oder ein Industriegebiet ist. Für diese Info muss ich dann n^(n-1) Polygone durch parsen ; wobei n dann nur noch die Anzahl der Polygone ohne diesen (Zusatz-)Tag ist.
Noch einmal ohne Wald:
Es geht um unterschiedliche Flächeneigenschaften. Renderer haben Mechanismen, nach denen Sie automatisiert bestimmte Flächen über andere zeichnen. Unter bestimmten Bedingungen (z.B. bei gleichem Schlüssel) bleibt dies allerdings dem Zufall überlassen, was dazu führt, dass in Darstellungen des Datenbankinhalts Införmationen fehlen. Wenn ich dem Renderer oder anderen Auswertungen nun helfe, indem ich durch verschiedene Flächenschlüssel für eher überwiegende Nutzungen (Landwirtschaft) und eher exklusive Nutzungen (Wiese) verwende, kann eine Hierarchie programmiert werden, wonach exklusive Nutzungen über überwiegende Nutzungen darzustellen sind. Funktioniert ja auch bei Parkplätzen und Häusern, soweit sie als Polygone in der Datenbank erfasst sind.
ich darf Deinen Satz mal umformulieren?
Es geht um unterschiedliche Flächeneigenschaften. Renderer haben Mechanismen, nach denen Sie automatisiert bestimmte Flächen über andere zeichnen. Unter bestimmten Bedingungen Bei fehlerhaftem Erfassen von Flächen (z.B. bei gleichem Schlüssel) bleibt dies allerdings dem Zufall überlassen, was dazu führt, dass in Darstellungen des Datenbankinhalts Införmationen fehlen
Einverstanden 
Nochmal: Ich will die Flächen nicht übereinander malen, sondern ich will den Flächeninhalt einer Fläche mit dem Merkmal A.
Bspw.
Die Fläche mit Merkmal A (Fläche A) sie ein Rechteck. Innerhalb dieser Fläche befindet sich eine Fläche mit dem Merkmal B (Fläche B), die man aber nicht zu A hinzurechnen kann und ebenfalls ein Rechteck ist. Die gesuchte Größe wäre also Fläche A - Fläche B
Beim MP:
Finde eine Fläche A; schaue ob MP; wenn ja, dann Suche Fläche B; Berechne den Flächeninhalt; suche nächste Fläche A
Bei deiner Methode:
Finde eine Fläche A; finde alle Flächen, die nicht die bereits gefundene sind und prüfe, ob sie geometrisch innerhalb von der gefundenen Fläche liegen; Berechne Flächeninhalt; suche nächste Fläche A
jetzt, Michael, jetzt hats Klick gemacht.
Wenn ich Dich recht verstehe, willst Du die bisherigen Landuse Tags ordentlich kürzen, also bspw landuse=“bebaute Fläche”, landuse=“Grünzeugs” etc. für die überwiegenden Eigenschaften. Alles was da drauf ist, ist automatisch bevorzugt. Dazu gibt es dann ausschliessliche Tags. Wenn das die Programme begreifen würden, könnte man einige MPs einstampfen. Hätte auch den Charme, dass man einfacher gering vergrößerte Übersichtskarten machen könnte.
Es gibt aber auch dabei einige Probleme. Zum einen wirst Du es nie vermeiden können, dass Beziehungen zweier Polygone zueinander mit inner und outer beschrieben werden müssen.
Und zum anderen müsste man doppelt erfassen. Wenn ich einen echten Wald mit Wiese drin erfassen möchte, müsste ich -wenn ich Dich richtig verstehe, den überwiegenden landuse=“Wald und ähnliches Zeugs” Tag setzen und zusätzlich den ausschliesslichen natural=“hier ist ausschliesslich Wald”. Aus dem natural=“hier ist ausschliesslich Wald” würde ich dann die Wiese ausschneiden, aus dem anderen Tag nicht.
Und es würde die Anzahl der Tags erhöhen (Wald ausschliesslich + Wald überwiegend etc)
Ist das so richtig?
Thomas, wenn dem so wäre, könnte man als Auswerter auch einfach die Tatsache landuse=“Wald und anderes drin” generieren aus dem Polygon mit landuse=forest und der Relationseigenschaft outer.
@aighes:
Wenn du aus OSM genaue Flächenberechnungen willst, bezweifele ich, dass die Datenqualität dazu reicht, denn wenn ein Mapper vergisst, einen inner-Fitzelchen auszustanzen, stimmt deine schöne Berechnung nicht mehr (von den erfassungsbedingten Ungenauigkeiten mal ganz abgesehen) 
Wenn es dir darum geht, in der Datenbank genaue Flächeneigenschaften zu hinterlegen und auf Karten zu sehen, welche Flächeneigenschaft eine Teilbereich hat:
Dann ergänze bitte deine letzte Änderung hier:
http://www.openstreetmap.org/browse/way/83429963
(inner ohne key/value; fixing multipolygons Ende März; einen Grund dafür sehe ich nicht )
…und übrigens:
soweit ich weiß, malen (bzw. zeichnen) in mehreren Durchläufen Renderer übereinander.
@ SunCobalt
Dein Klick erfreut mich. Allerdings will und kann mein Vorschlag bei gleichen Flächen-Schlüsseln MP’s nicht verhindern, und einige sinnvolle zusätzliche Tags, die dann für Klarheit und vereinfachtes Mapping/Rendering (jawoll, auch das! ) sorgen, sind doch kein Schaden. 
Bin jetzt weg; Chips essen
landuse=residential ist für mich das klassische Beispiel.
Es beschreibt ein Konklomerat von allem Möglichen, aber es ist allgemein akzeptiert, dass spezielle Gebiete wie Gebäude!!, Spielplätze usw. konfliktfrei betrachtet ud dargestellt werden.
Insofern macht es Sinn, auch für andere Gebiete, den “Default” Hintergrund zu definieren, mit dem Hintergedanken, dass alles was darin an speziellem gemappt wird, quasi eine Ebene drüber steht.
Beispiel: farmland: das kann meiner Meinung nach auch eine Bauerhof (mit Gebäuden und Hofflächen) aber auch eine Wiese (meadow) einschließen, ohne dann ein kompliziertes MP Konstrukt ensteht.
Aber das ist alles eine Frage der Semantik, und die lässt sich nach meinem Kenntnisstand leider nicth formal eindeutig beschreiben.
naja, mit Fehlern zu argumentieren, ist nicht besonders fair. Wenn etwas falsch ist, kann ein darauf resultierendes Ergebnis nie richtig sei.
Ich habe das Gefühl, wir werden uns nicht annähern.
Ich habe mal eine Wiese an den von Dir genannten Way gehängt. Allerdings scheint der Wald aus vor-Bing Zeiten zu stammen. Vielleicht magst Du den mal zurecht zupfen. Das geht auch ohne MPs
Wenn du den Grund nicht siehst, kann ich ja nichts dafür. Das ein MP mit den gleichen Tags am outer und inner-Polygon unsinnig ist, ist aber nichts neues.
Ebenfalls spielt die Unsicherheit keine Rolle, da die geometrischen Abweichungen bei beiden Varianten die gleichen sind.
Das Rendering ist einfacher, wenn man alles einfach rendert. Das hat dann aber nichts mehr mit richtig zutun. Wie sieht es bei 3facher Verschachtelung aus? Also Wald, Wiese, See aus? Dann hat man außen ein “Wald mit was drin” darin dann ein “Wiese mit was drin” und dann einen See. Woher weiß ich jetzt als renderer, ob ich zuerst Wiese render soll oder zuerst Wald?
Übrigens jeder Renderer, der direkt ein xml oder pbf-File rendert, nimmt als Renderreihenfolge von Objekten die Reihenfolge der Objekte in der Datei. Bei diesen Renderern funktioniert deine Methode gar nicht.
Das ist der entscheidende Punkt: Der Vorschlag hier erleichtert nur scheinbar den Umgang mit den ueberlagernden Flaechenelementen, weil er suggeriert, dass sich der Mapper nicht mehr darum kuemmern braucht. Was dabei rauskommt ist aber am Ende viel unuebersichtlicher als das jetzige multipolygon-Durcheinander, da es fuer alle Beteiligten schwieriger wird, genau zu definieren bzw. zu erkennen, welche Eigenschaften nun fuer eine Teilflaeche gelten und welche nicht.
Es wuerde schon viel helfen, wenn man bei dem Thema nicht immer an die Renderer-Sicht denken wuerde. Denn auf der Karte wird fuer ein Teilflaeche meist nur eine Eigenschaft angezeigt. (Inzwischen ist immerhin erkannt worden, dass man einige beliebte Zusatzeiganschaften per transparentes Overlay ergaenzen sollte, z.B. Naturschutzgebiet) In der Realitaet haben wir es aber staendig mit vielen verschiedenen Eigenschaften gleichzeitig zu tun und das Problem ist, wie man diese Kombinationen am besten erfassen und anschliessend auch wieder auswerten kann.
Ein moeglicher Ansatz waere z.B., dass man Flaechenueberlappungen grundsaetzlcih ausschliesst. Das wuerde dann bedeuten, dass jedes Flaechenelement eindeutig durch seine Position bestimmt ist, und man dann halt fuer dieses Element alle dort gueltigen Eigenschaften eintraegt. Das waere schoen uebersichtlich und auch einfach auszuwerten, aber viel viel aufwendiger ind er Erfassung der Daten, da man z.B. nicht einfach ein Polygon um ein Gebiet zeichnen kann, sondern jedes enthaltene Element einzeln taggen muesste.
Gruss
Torsten
Erklär mir doch bitte nochmal dein Layerproblem? Ich meine etwas weiter unten schreibst du, dass man jetzt die Fläche A nimmt und davon Fläche B abzieht, wenn Fläche B in Fläche A liegt. Das gleiche kannst du auch über die Layereigenschaft machen. Ziehe Fläche B von Fläche A ab, wenn Fläche B in Fläche A und der Layer größer ist als bei Fläche A. Das spart dir die tollen Ersetzungstabellen. Denn dann kannst du eine Tiefgarage auch unter das Wohnviertel packen. Ob ein Parkplatz jetzt Wohngebiet ist oder nicht, kann man sicher diskutieren. Aber dann dürften alle Verkehrsflächen nicht Wohngebiet sein. Für den Renderer wird die Sache etwas schwieriger. Denn der muss die Tiefgarage in jedem Falle über das Wohngebiet legen, da sonst die Tiefgarage “übermalt” wird. Aber das Problem hat man auch heute schon.
Weil layer=* angibt wie die Objekte in z-Richtung angeordnet sind und nicht die Reihenfolge, in der die Flächen gerendert werden. Eine Wiese liegt nicht oberhalb vom Wald, sondern auf der gleichen Ebene (Erdboden), weshalb sich der layer nicht unterscheiden kann.
Wer sagt, dass der Renderer die Tiefgarage drüber rendern muss? Das sagt das Style-File, aber nicht der Mapper. Der Mapper sagt, dass die Tiefgarage unterhalb der Erdoberfläche liegt.