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

kreuzschnabel · 2015-12-05 21:39:53

wambacher wrote:

kreuzschnabel wrote:
Dies als grundsätzliches Vorgehen beim Rendern zu machen, hätte einen Haufen Vorteile, hier mal zwei:
...
Welche Nachteile hätte es? Mir fallen keine ein.
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?

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

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

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?

Und was ist mit Wald - Wiese - Baumgruppe? Kleine Flächen sind stärker als grosse Flächen?

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

Last edited by kreuzschnabel (2015-12-05 21:41:10)

Weide · 2015-12-05 23:04:09

kreuzschnabel wrote:

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

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

geow · 2015-12-05 23:21:14

kreuzschnabel wrote:

Wir stehen vor der Grundsatzfrage: Wollen wir ein Geodienst sein, bei dem jeder mitmachen und zu dem jeder beitragen kann?
....
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.

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

wambacher · 2015-12-05 23:27:37

geow wrote:

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.

Ymmd

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

Danke und Gruss
walter

Weide · 2015-12-06 08:20:42

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

Last edited by Weide (2015-12-06 08:21:22)

cepesko · 2015-12-06 08:24:51

...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.

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

chris66 · 2015-12-06 10:33:30

Weide wrote:

Wir sollten in OSM als Objekttypen außer Punkten, Linien und Relationen auch Flächen haben.

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

Geofreund1 · 2015-12-06 11:51:03

Meine Befürchtung Richtung "MP Überflutung" scheint sich zu bewahrheiten:

man muss nicht nur landuse und natural ausschneiden sondern auch Parkplätze, Recyclingplätze und Sportstadien (und wahrscheinlich noch viel mehr).

Last edited by Geofreund1 (2015-12-06 12:08:49)

slhh · 2015-12-06 12:15:17

wambacher wrote:

- 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.

Dies würde aber einen Missbrauch des Multipolygons darstellen, wobei das Multipolygon zusätzlich zur Multipolygon-Flächen-Eigenschaft "bewaldete Fläche" der vom Outer umfassten Fläche noch die zusätzliche Flächen Eigenschaft "Waldfläche" implizit zuordnen soll.

Wenn man diese Information in der Datenbank haben will, so muss man Waldfläche und bewaldete Fläche getrennt erfassen. Man könnte natürlich den Outer-Weg des MP als "Wald" und das MP als "bewaldete Fläche" täggen.

Ich habe aber arge Zweifel, ob es den Mappern einigermaßen objektiv gelingen würde, die "Waldfläche" zu erfassen. Da wäre es wohl deutlich objektiver, die Waldfläche mitttels einer geeigneten mathematischen Definition aus den bewaldeten Flächenstücken zu berechnen, auch wenn diese Berechnung sicher nicht ganz trivial ist.

wambacher · 2015-12-06 12:47:29

slhh wrote:

Dies würde aber einen Missbrauch des Multipolygons darstellen, wobei das Multipolygon zusätzlich zur Multipolygon-Flächen-Eigenschaft "bewaldete Fläche" der vom Outer umfassten Fläche noch die zusätzliche Flächen Eigenschaft "Waldfläche" implizit zuordnen soll.
Wenn man diese Information in der Datenbank haben will, so muss man Waldfläche und bewaldete Fläche getrennt erfassen. Man könnte natürlich den Outer-Weg des MP als "Wald" und das MP als "bewaldete Fläche" täggen.

Da hast du wohl was falsch verstanden: Ich will keine weiteren Werte in die DB "schmuggeln", sondern zeigen, dass sie schon längst drin sind. Dafür braucht man den Outer-Weg eben nicht extra als Wald zu taggen. Das ist er längst schon.

Es gibt Standardfunktionen (bei PostGIS z.B. ST_ExterriorRing(geometry) ), die dir den "Wald ohne Löcher" liefert, wenn du diesen haben willst. Willst du nur die Waldfläche (Wald mit Löchern"), nimmst du halt das ganze MP.

Es gibt dutzende solcher Geometrie-Funktionen, die solche Informationen aus den bereits vorhandene Daten besorgen können - wenn diese einigermassen OGC-konform sind.

Das ach so beliebte Rendern als "DAS Qualitätskriterium" für viele Mapper geht dadurch übrigens auch einfacher: Wenn ein MP sauber ist, braucht sich der Renderer keine "Gedanken" darüber zu machen, was wo wie warum gefärbt werden soll. Und genau das war die Absicht bei der Umstellung vom Herbst.

Gruss
walter

ach ja: Nicht dass du denkst "Was soll ich mit PostGIS?" - Mapnik und die anderen mir bekannten Renderer verwenden selbstverständlich PostGIS um an ihre OSM-Objekte heranzubekommen. Und da stehen den Style-Erstellern natürlich alle GIS-Funktionen zur Verfügung.

Last edited by wambacher (2015-12-06 12:51:46)

Geofreund1 · 2015-12-06 13:22:23

Es gibt auch noch gute Nachrichten:
natural innerhalb natural (z. B. water innerhalb scrub) muss man nicht ausschneiden und es wird trotzdem korrekt dargestellt!

Wieso das jetzt wieder anders gehandhabt wird als bei landuse verstehe wer will...

chris66 · 2015-12-06 13:26:51

''Geo''freund1 wrote:

natural innerhalb natural (z. B. water innerhalb scrub) muss man nicht ausschneiden

Natürlich muss man water innerhalb scrub ausschneiden.

Last edited by chris66 (2015-12-06 13:27:49)

Geofreund1 · 2015-12-06 13:44:11

@chris66:
guckst du hier:

http://www.openstreetmap.org/#map=19/48.87182/8.62310

wambacher · 2015-12-06 14:17:12

Geofreund1 wrote:

Wieso das jetzt wieder anders gehandhabt wird als bei landuse verstehe wer will...

Hab mir den aktuellen Carto-Style nicht näher angeschaut, nehme aber an, dass "Wasser" wie bisher nach den diversen Flächen gerendert wird und dadurch automatisch oben liegt.

Das kann/darf /soll(?) sich aber jederzeit ändern.

Gruss
walter

Weide · 2015-12-06 14:22:56

Geofreund1 wrote:

@chris66:
guckst du hier:
http://www.openstreetmap.org/#map=19/48.87182/8.62310

Man kann nicht von der Landkartenerzeugung verlangen, dass sie alles Falsche auch falsch darstellt.

Das kommt eben zufällig richtig raus und es kann morgen auch zufällig anders rauskommen. Nur wenn die Daten stimmen, kann man von der Landkarte die richtige Ausgabe verlangen. Wenn die Daten nicht stimmen, dann kann alles Mögliche angezeigt werden.

Weide

PS: Ich hab mir allerdings schonmal 'ne Karte gewünscht, in der alles Fehlerhafte weggelassen wird. Mit so einer Karte will ich aber bestimmt nicht wandern ... aber zum Mappen wäre sie praktisch.

slhh · 2015-12-06 14:27:13

wambacher wrote:

Da hast du wohl was falsch verstanden: Ich will keine weiteren Werte in die DB "schmuggeln", sondern zeigen, dass sie schon längst drin sind.

Das habe ich schon verstanden und genau da liegt das Problem. Du implizierst einfach Eigenschaften des Outer die so von der Definition der Daten nicht gedeckt werden. Hier einige Beispiele, warum das nicht funktioniert:

Wenn beispielsweise eine Großstadt oder ein großer See von einem geschlossenen Waldring umgeben sind, könnten Stadt oder See per Inner eines MP ausgeschnitten sein. Wären sie deshalb aber Bestandteil einer Waldfläche?
Wenn ein Mapper unhandbar große MP aufteilt, könnten aus bisher ausgeschnittenen Flächen teilweise Flächen außerhalb des MP werden. Dies könnte die berechnete Waldfläche wesentlich verändern.
Wenn ein Mapper statt eines MP mehrere Teilflächen verwendet, ändert dies die berechnetze Waldfläche auch wesentlich.

Geofreund1 · 2015-12-06 15:17:55

@Weide
"Man kann nicht von der Landkartenerzeugung verlangen, dass sie alles Falsche auch falsch darstellt."

Hilf doch bitte einem armen Mapper auf die Sprünge und verrate mal, wo das alles definiert ist, was da richtig oder falsch ist. Aber bitte nicht das wiki mit De:Relation:multipolygon.

Dort sollte dann auch stehen, wieso Gebäudeflächen anders behandelt werden als andere Flächen.

Geofreund1 · 2015-12-06 15:26:36

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

So ist es anscheinend doch nicht. Bitte selbst ausprobieren.

Geofreund1 · 2015-12-06 15:35:55

@wambacher
"Hab mir den aktuellen Carto-Style nicht näher angeschaut, nehme aber an, dass "Wasser" wie bisher nach den diversen Flächen gerendert wird und dadurch automatisch oben liegt."

Nö, so ist es auch nicht: natural=water innerhalb natural=wetland sieht ziemlich zugewachsen aus.

Nop · 2015-12-06 16:29:37

Es ist egal, ob der aktuelle Carto-Style etwas zufällig richtig oder falsch rendert. Das kann sich jederzeit ändern und gilt auch nur für diese eine Karte.

Gormo's Hinweis im Wiki wurde übrigens schon wieder entfernt ohne daß sich Cmuelle8 zu einer Diskussion mit uns hier herabläßt. Ich würde jemand anders bitten, das zu reverten.

bye, Nop

Weide · 2015-12-06 16:38:20

Geofreund1 wrote:

Dort sollte dann auch stehen, wieso Gebäudeflächen anders behandelt werden als andere Flächen.

Die einzigen besonderen Flächen sind meines Wissens die Landuse-Flächen. Das liegt daran, dass landuse als "überwiegende Nutzung" definiert ist. Daher kann es grundsätzlich keine zwei zutreffenden landuse an einer Stelle geben, weil ja nicht beide überwiegen können. Das war ursprünglich dazu gedacht, dass man z.B. das "Industriegebiet Ost" mit einem Namen und einer Hintergrundfarbe auf der Karte darstellen kann. Alles andere kam in der Karte drüber. Einzelne Wohnhäuser oder ein Teich können ja in einem Industriegebiet liegen. Im Rahmen des Detailmapping wurde das dann soweit in kleine Teile aufgespalten, dass diese Besonderheit eigentlich nicht mehr zutrifft. Aber wir müssen jetzt damit leben.

Geofreund1 wrote:

Aber bitte nicht das wiki mit De:Relation:multipolygon

Sorry, das kann ich nicht auslassen :-)
Ich hab eine Beschreibung unter http://www.gafte.de gestellt. Das ist ein pdf und kein Wiki :-))

Im Ernst: Außer landuse sind alle Flächen meines Wissens gleich. Alle Flächen werden über ihren Rand angegeben. Besteht der Rand aus nur einem Objekt, dann kann man gewöhnlich das Objekt für die Tags nehmen. Ansonsten gibt man die Liste der Randobjekte in einem MP an und schreibt die Tags ins MP. Was in irgendwelchen anderen Datensätzen steht spielt keine Rolle und ändert nie etwas an der Fläche. Sogar die Tags der im MP genannten Datensätze sind unerheblich.

Weide

maxbe · 2015-12-06 16:54:02

Ich würde davon abraten, irgendwelche Aussagen wie "X wird immer über Y gerendert" zu treffen, ohne das im Stil nachzusehen. Selbst Kenner des Stils werden im Einzelfall darauf reinfallen, dass irgendwelche unbeabsichtigten Seiteneffekte aus ganz anderen Tags ein Ergebnis erzeugen. Aussagen, die sich nur auf den Key ohne den Wert beziehen (sowas wie "landuse darf natural überlagern") sind praktisch immer falsch. landuse=basin wird derzeit z.B. zusammen mit natural=water und waterway=* gerendert, letzteres aber nur, wenn building nicht gesetzt wird.

So im wesentlichen gibt es 4 bis 5 Arten, Flächen zu überlagern:

* Flächen überlagern Flächen, wenn sie einem später gerenderten Layer ("Layer" im Sinne von Mapnik, nicht im Sinne von OSM-Tags) angehören. Beispiel: Häuser stehen über dem Industriegebiet und Fussgängerzonen überlagern Häuser.
* Flächen überlagern Flächen, wenn sie dem gleichen Layer angehören, aber kleiner sind. Beispiel: Wasser über Wiese.
* Flächen überlagern Flächen mit ihrem farbigen Hintergrund, die Symbole der "unteren" Fläche werden gemalt, bevor die "obere" Fläche gezeichnet wird. Beispiel: Wasser über Büschen.
* Flächen überlagern Flächen mit ihrem farbigen Hintergrund, die Symbole der "unteren" Fläche werden aber nach allen anderen Flächen dieses Layers oder aller Layer über die gesamte Fläche gemalt. Beispiel: Wasser über Wald.
* Flächen überlagern Flächen, die "untere" Fläche hat aber keinen eigenen farbigen Hintergrund, sondern ist transparent. Da gibt es die beide letztgenannten Möglichkeiten zur Anordnung der Symbole. Beispiel: Sumpf über Wasser.
* Wären die Macher des Stils Freunde von halb transparenten Flächen, gäbe es noch ein paar Möglichkeiten.

Ich glaube, es macht keinen Sinn, bei dieser Vielfalt irgendwelche Regeln anhand von Beispielen rauszusuchen. Gar keinen Sinn hat es, daraus Regeln fürs Mappen abzuleiten. Andere Stile haben andere Reihenfolgen und es gibt ja sogar Karten, die nicht mal mit Mapnik gemacht werden.

Grüße, Max

Last edited by maxbe (2015-12-06 17:01:17)

Chrysopras · 2015-12-07 07:30:54

Nop wrote:

Gormo's Hinweis im Wiki wurde übrigens schon wieder entfernt ohne daß sich Cmuelle8 zu einer Diskussion mit uns hier herabläßt. Ich würde jemand anders bitten, das zu reverten.

Done.

Ich habe Gormos Hinweis noch mit diesem (sehr moderat formulierten!) Satz ergänzt: "Insbesondere wird inzwischen häufig davon abgeraten, Wege (highways) als Outer-Linien von Multipolygonen zu benutzen."

Last edited by Chrysopras (2015-12-07 07:36:34)

RadFr · 2015-12-07 12:59:05

Chrysopras wrote:

Nop wrote:
Gormo's Hinweis im Wiki wurde übrigens schon wieder entfernt ohne daß sich Cmuelle8 zu einer Diskussion mit uns hier herabläßt. Ich würde jemand anders bitten, das zu reverten.
Done.
Ich habe Gormos Hinweis noch mit diesem (sehr moderat formulierten!) Satz ergänzt: "Insbesondere wird inzwischen häufig davon abgeraten, Wege (highways) als Outer-Linien von Multipolygonen zu benutzen."

Das ist IMO viel zu schwach formuliert. Habe aus genanntem Grund einen Mapper angeschrieben, bis dato ohne Antwort.

gormo · 2015-12-07 13:04:40

RadFr wrote:

Chrysopras wrote:
Nop wrote:
Gormo's Hinweis im Wiki wurde übrigens schon wieder entfernt ohne daß sich Cmuelle8 zu einer Diskussion mit uns hier herabläßt. Ich würde jemand anders bitten, das zu reverten.
Done.
Ich habe Gormos Hinweis noch mit diesem (sehr moderat formulierten!) Satz ergänzt: "Insbesondere wird inzwischen häufig davon abgeraten, Wege (highways) als Outer-Linien von Multipolygonen zu benutzen."
Das ist IMO viel zu schwach formuliert. Habe aus genanntem Grund einen Mapper angeschrieben, bis dato ohne Antwort.

Ja, aber auch wenn wir im Forum hier konsens haben, ist es ja scheinbar in der großen Community kein Konsens. Das hab ich falsch eingeschätzt. Ich glaube, wir müssen die Diskussion in die Community, mindestens ins Wiki, tragen, da das ja scheinbar doch kontrovers ist.

Announcement

#51 2015-12-05 21:39:53

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

#52 2015-12-05 23:04:09

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

#53 2015-12-05 23:21:14

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

#54 2015-12-05 23:27:37

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

#55 2015-12-06 08:20:42

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

#56 2015-12-06 08:24:51

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

#57 2015-12-06 10:33:30

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

#58 2015-12-06 11:51:03

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

#59 2015-12-06 12:15:17

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

#60 2015-12-06 12:47:29

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

#61 2015-12-06 13:22:23

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

#62 2015-12-06 13:26:51

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

#63 2015-12-06 13:44:11

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

#64 2015-12-06 14:17:12

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

#65 2015-12-06 14:22:56

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

#66 2015-12-06 14:27:13

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

#67 2015-12-06 15:17:55

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

#68 2015-12-06 15:26:36

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

#69 2015-12-06 15:35:55

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

#70 2015-12-06 16:29:37

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

#71 2015-12-06 16:38:20

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

#72 2015-12-06 16:54:02

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

#73 2015-12-07 07:30:54

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

#74 2015-12-07 12:59:05

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

#75 2015-12-07 13:04:40

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

Board footer