Ausschneiden von Flächen (Lichtung mit Gras) in Flächen (Wald)

Landläufig ist es doch so, dass leisure und amenity nicht ausgeschnitten werden, nur landuse und natural aus selbigen.

Deswegen Überflutung? Sehe ich nicht so.

Es gibt Mapper, die alles (alle Flächen, Gebäude usw.) per MP erfassen, obwohl da ein einfaches Polygon reichen würde.
Da würde ich dann von Überflutung reden.

Was IMO auch nicht geht, ist die Nutzung von highway als outer in einer MP-Relation.

Cmuelle8 hat die Warnung vor Multipolygonwahnsinn erneut entfernt. Diesmal habe ich seine Änderung reverted.

Eine Teilnahme an der Diskussion hier kann ich nicht feststellen, er scheint einen Editwar vorzuziehen.

bye, Nop

Es kommt immer auf den Einzelfall an.
Beispiel: Spielplatz (leisure=playground) in einem Wald (landuse=forest).

Wenn in den Wald eine Lichtung geschlagen wurde, um den Spielplatz zu errichten, dann ist auch in OSM ein Loch in den Wald zu schneiden (MP).

Wenn da keine Bäume gefällt wurden, sondern die Spielgeräte zwischen den Bäumen aufgestellt wurden, braucht in OSM kein Loch aus dem Wald ausgeschnitten werden. Die Flächen (playground und forest) liegen dann in OSM “übereinander”.

Beide Fälle werden in der OSM “Hauptkarte” korrekt gerendert, einmal mit und einmal ohne Baumsymbole innerhalb der Spielplatzfläche.

Ein MP ist immer eine Fläche. Die Tags des MP geben die Flächeneigenschaften an. Hat das MP eine “inner” Fläche, dann gelten die Eigenschaften des MPs in dem Loch nicht.

Grüße
Chris

Mal an einem willkürlichen Beispiel diskutiert:

http://www.openstreetmap.org/#map=17/48.74474/8.79150

wie würde man denn - mit den derzeitigen Renderregeln - den Baumbewuchs im landfill loswerden, ohne MP ?
Ich würde es für wesentlich besser und einfacher halten, wenn diese ewige Ausschneiderei ein Ende hätte.

Ungünstiges Beispiel, der Wald “Eulhart” ist eh schon ein MP wegen der Wiese. Ansonsten müsste der Waldverlauf entlang der Zufahrtsstraße verlaufen, dann um das Müllgelande drumherum auf der anderen Seite der Zufahrtsstraße zurück, was das ganze aber auch nicht einfacher macht. Richtiger wäre es schon. Eine Straße, selbst wenn es nur eine 5 m breite Zufahrt ist, unterbricht den Wald immer.

Das sehe ich als zwei Fragen:

  1. Wie wird man den Wald auf der Deponie los?
    Das ist einfach. Man schreibt nicht in die Daten, dass da Wald wäre.

  2. Geht das ohne MP?
    Das kommt darauf an, ob “Eulhart” wirklich der Name dieses Wald- und Deponiegebietes jedoch ohne die Wiese ist. Das ist das, was da im Moment in den Daten steht … aber ob das so stimmt?.

Weide

@Rogehm
“Eine Straße, selbst wenn es nur eine 5 m breite Zufahrt ist, unterbricht den Wald immer.” Wo bitte ist das denn definiert?

@Weide
zu 1. in landuse=landfill steht nicht drin, dass da Wald sei.
zu 2. Nimm mal an, dass das Gebiet wirklich so heißt; wie sieht deine Lösung dann aus?

Es steht im MP.

Schwer zu sagen: In den Daten steht jetzt, dass es der Name des Waldes ist und er bezieht sich auch auf die Deponie. Wenn man die Deponie aus dem Wald rausnimmt, ist dann das Gebiet für den Namen auch verändert?

Aber ich will mich nicht vor konkreten Sachen drücken: Wenn das ganze Gelände inclusive Deponie und Wiese den Namen hat würde ich Folgendes machen:

Ganz außen eine geschlossene Linie mit place=locality; name=Eulhart

Sowohl die Wiese als auch die Deponie als in sich geschlossene Linie mit den üblichen Tags.

Den Wald in zwei Teilen jeweils als in sich geschlossene Linien, so dass Deponie und Wiese dazwischen liegen.

Weide

IMO ist das nicht so einfach:

  1. Das MP hat den Namen Eulhart
  2. Es gibt 2 place-POIs (Eulhart und Im Eulert).

Insofern könnte man den Wald entsprechend der place teilen, so deren Grenzen bekannt sind. Ansonsten Wald-MP (ohne name-Tag) und POIs belassen, Deponie als inner dazu. Den Wald nur deshalb querbeet zu teilen, um die MP-Relation zu meiden, halte ich für nicht gerechtfertigt.

Jetzt nimm einmal an, dass Deponie und Wiese nachträglich eingefügt werden sollen. Es war also nur 1 Wald da. Dann hast du mit dem Auftrennen und neu zeichnen richtig Arbeit.

Ich fände es besser, wenn geschlossene Flächen, die innerhalb weiterer geschlossener Flächen liegen, einfach so dargestellt werden, wie sie getagged sind. So war es früher ja auch. Und um ein Haus in einem Wald wird doch auch nicht der Wald kunstvoll herumgeführt. Wo ist denn da der Unterschied in der Logik?

Ich empfehle für diejenigen, die nichts zu tun haben, sich mal die Gegend

http://www.openstreetmap.org/#map=16/44.6484/-1.0184

vorzunehmen. Da kann man sich mit dem “Herumführen” so richtig austoben.

Ob das, was im MP steht, für eine kleinere Fläche innerhalb des MP immer noch gilt, ist doch eine reine Definitionsfrage. Momentan ist es bei anderen landuses, naturals und riverbanks so, aber wir können genausogut festlegen: Wenn innerhalb eines landuse=forest (sei es als MP oder als Way) ein landuse=meadow liegt, dann hört in diesem Bereich der landuse=forest auf. Ganz einfach. Er wird vom landuse=meadow transparenzlos überdeckt. Ebenso alle anderen Flächen: Kleinere Flächen innerhalb von größeren liegen grundsätzlich „drüber“.

Woanders machen wir es auch so, ohne Probleme. Gebäude wurden schon genannt. Und in ein landuse=residential kann ich problemlos ein landuse=village_green reinmappen, ohne extra eine Aussparung vorzunehmen. Wozu auch? Ist doch vollkommen klar, daß in diesem Bereich der residential Pause hat, was auch sonst?

Dies als grundsätzliches Vorgehen beim Rendern zu machen, hätte einen Haufen Vorteile, hier mal zwei:

  • Man müßte nicht für jede inselbehaftete Fläche ein MP anlegen. Ein geschlossener Way ist einfacher anzulegen und zu pflegen und tut es auch.

  • Jeder andere Mapper, der eine Teilfläche innerhalb dieses Waldes eintragen möchte, tut das ganz einfach, ohne erst recherchieren zu müssen, ob er eventuell in einem MP arbeitet, dem er seine neue Fläche noch als inner einverleiben muß. (Bei großen MPs ist das gar nicht so leicht zu erkennen – wenn der Editor noch kein outer-Element heruntergeladen hat, wird auch noch keine Flächentönung angezeigt, wie denn auch).

Welche Nachteile hätte es? Mir fallen keine ein.

–ks

Da wir ja nicht für den Renderer taggen wollen, sollte es primär nicht um die Darstellung, sondern um die Definition der Bedeutung gehen.
Wie dann korrekt zu rendern ist, ergibt sich aus der definierten Bedeutung.

Es erscheint mir aus folgenden Gründen problematisch, einfach zu definieren, dass die kleinere innere Fläche die Bedeutung grundsätzlich überschreibt:

  • Dies würde bedeuten, dass man niemals die Eigenschaften beider Polygone in der inneren Fläche kombiniert hat. Dies mag für manche Tag-Kombinationen auch passend sein, jedoch wohl nicht für alle. Wenn man die Regel zu abhängig von bestimmten Tags macht, wird es wieder sehr kompliziert.

  • Teilt jemand die äußere Fläche, so kann dies dazu führen, dass die ehemals innere kleine Fläche nicht mehr komplett in einem der Teile der äußeren Fläche liegt und somit würde die Bedeutung der ehemals inneren kleinen Fläche ggf. unbemerkt geändert. Es ist auch nicht sichergestellt, dass die ehemals innere kleine Fläche tatsächlich noch kleiner ist, als die Teilflächen der äusseren Fläche.

Alternativen, die man dagegen sinnvoll definieren kann, wären:

  • Mehrere verschiedene Landuse-Schlüssel wie default-landuse=, landuse= und landuse-override=* mit klar definierter Priorität.

  • Ein zusätzlichliches Tag wie cutout=landuse an der inneren Fläche könnte das landuse einer überlagerten Fläche übersteuern.

Der erste Teilsatz sagt es doch schon: Dieser Vorschlag soll für das Rendern gelten.
Aber sobald man über den Tellerrand hinausblickt, wird es damit schwierig.

  • wie gross ist die bewaldete Fläche?
  • wie gross ist der Wald?

Bei einem sauber als MP erfassten Wald (MP natürlich hier nur, weil der Wald Löcher hat!) ist das ganz einfach.

pseudo-GIS:

  • bewaldete Fläche = area(Fläche)
  • Waldfläche = area(exterrior(Fläche))

exterrior ist der Umfang der Fläche, so als ob die Löcher nicht existieren würden.

versuche das mal für sich überlagernde Flächen (Papier - Schere - Stein: Wiese ist stärker als Bäume) auszuwerten.
Und was ist mit Wald - Wiese - Baumgruppe? Kleine Flächen sind stärker als grosse Flächen?

Nee, das kann und wird nicht gut gehen.

Gruss
walter

tl;dr: Rendern ist hübsch - saubere geographische Objekte sind kritisch.

Wollen wir wirklich amtliches Kataster fahren? Dann sind wir als Wiki-Projekt aber denkbar schlecht aufgestellt, dafür braucht es qualifiziertes Fachpersonal.

Wenn unsere Datenquellen präzise genug dafür wären, ja. Aber willst du einen nach Bing abgezeichneten Wald (wo in der Regel die Baumkronen gemappt sind, nicht der Waldrand am Boden) wirklich als Grundlage einer quadratmetergenauen Flächenmessung heranziehen?

Genau das war mein Ansatz, ja.

Wir stehen vor der Grundsatzfrage: Wollen wir ein Geodienst sein, bei dem jeder mitmachen und zu dem jeder beitragen kann? Eines, das eher Vollständigkeit anstrebt als Präzision? Eines, das lieber ein POI zehn Meter neben der Position verzeichnet hat als im Zweifelsfall gar nicht? Dann sollten wir die Einstiegsschwelle möglichst niedrig halten. Das heißt für mich, daß man nicht Multipolygone verstanden haben muß, bevor man eine Wiese einzeichnen kann.

Oder wollen wir präzises GIS abliefern? Dann müssen wir vom Jeder-kann-mitmachen-Ansatz ganz schnell abspringen und nur noch Geoingenieure beschäftigen.

–ks

Beim Schreiben? Keine.
Beim Lesen: ungeheuer viele.

Wenn in einem Datensatz etwas drinsteht, dann sollte es auch so sein. Man sollte nicht die gesamte Datenbank nach anderen Datensätzen durchsuchen müssen um festzustellen, was denn nun davon wirklich stimmt. Wir müssten alle möglichen Tags in eine komplizierte und klare und hochgradig veränderliche Hierarchie bringen. Keiner könnte mehr beurteilen, ob irgendwo ein Wald ist, wenn er nicht die neuesten Entwicklungen im Tagging von Naturschutzgebieten kennt.

Weide

So polarisiert würde ich das nicht sehen: Wer bei uns mitmacht, muss sich zum Einstieg nicht mit Multipolygonen beschäftigen. Andererseits ist die topologisch korrekte Erfassung einer Waldlichtung oder einer Insel mit Hilfe eines MP auch keine Geheimwissenschaft.

Wir stehen daher nicht vor einer Grundsatzfrage. Die Änderung im Mapnik-Style wurde nach gründlicher Diskussion entschieden und ist wohl durchdacht: Fehler in der Flächenerfassung kann jetzt jeder auf der Hauptkarte leicht erkennen und ändern. Vorher haben sich nur ein paar Experten mit QS-Tools daran versucht. Deshalb hat sich die Datenkonsistenz in diesem Punkt in den letzten Monaten auch deutlich verbessert.

Gruß
geow

Ymmd :slight_smile:

immer wieder diese Argumente erneut zusammenkratzen zu müssen, macht langsam keinen Spass mehr.

Danke und Gruss
walter

Da spielt evtl. auch noch eine andere Sache eine Rolle:

Wir sollten in OSM als Objekttypen außer Punkten, Linien und Relationen auch Flächen haben. Dann ist klar, welche Fläche (und ob überhaupt eine Fläche!) gemeint ist bevor noch irgendwelche Tags betrachtet werden. Wenn wir an diesem Punkt angekommen sind, dann können die Editoren Flächen auf ganz andere und für den Mapper viel einfachere Art unterstützen … z.B. durch Zusammenklicken oder Einkreisen von Flächenelementen im Bild. Das wäre dann endlich das Ende aller Multipolygone und aller mehrdeutigen Linien und die dann mögliche bessere Editorunterstützung würde das Editieren insbesondere für Nicht-Experten erheblich einfacher machen.

Wenn wir dahin kommen wollen, dann sollten wir jetzt keine Regeln einführen, die die spätere Umstellung behindern. Wir sollten viel eher solche schon vorhandenen Regeln loswerden.

(Z.B. area=yes ist überflüssig, wenn es laut Tagging sowie keine Linie sein kann. Das führt jetzt zu ungeahnten Auswirkungen bei Wikiänderungen (bei leisure=track gab es früher kein area=yes … dann wurden Flächen zugelassen und sämtliche bisherigen Datensätze hätten eigentlich konvertiert werden müssen) und zu Objekten mit sowohl barrier=fence als auch landuse=meadow

Weide

Seh ich auch so. Neumapper Jaeger52 jedenfalls hat nach einer kleinen Hilfestellung die Hürde MP bereits genommen und selbst korrekte PMs erstellt.
cepesko

Ja, das steht ja für die nächste API Version (seit Jahren) auf der Wunschliste.