Wald

Siehe:

http://forum.openstreetmap.org/viewtopic.php?id=54922

Also: Beantrage einen mechanischen Edit. Von alleine taggt sich der Wald nicht um. 😉

chris66 wrote:

...

Also: Beantrage einen mechanischen Edit. Von alleine taggt sich der Wald nicht um. 😉

Wer kennt sich damit aus? Wo kann ich so etwas beantragen?

M.M. nach sollte so etwas automatisch erfolgen, wenn es geändert wird. Es wurde ja bestehendes nur anders geschrieben.

Ich habe in meinem Bereich, diese Dinge ausnahmslos händisch geändert. Ich kann auch nichts anderes empfehlen... Solche Waldstruktur ist aber auch eine Sache, die man mit ein wenig Wissen, recht gut per Luftbild, sprich Bing, erledigen kann, ...z.B. das Osmose-Tool. Lediglich Lärchenforste bilden eine Ausnahme, da diese nadelförmig und laubabwerfend sind. Aber größerflächige Lärchenforste kenne ich zu mindestens in Ostdeutschland kaum...

Sven

chris66 wrote:

Siehe:

http://forum.openstreetmap.org/viewtopic.php?id=54922

Also: Beantrage einen mechanischen Edit. Von alleine taggt sich der Wald nicht um. 😉

-1

geri-oc wrote:

chris66 wrote:

...

Also: Beantrage einen mechanischen Edit. Von alleine taggt sich der Wald nicht um. 😉

Wer kennt sich damit aus? Wo kann ich so etwas beantragen?

Das Vorgehen ist prinzipiell unter folgendem Link beschrieben, aber in diesem Fall problematisch:
http://wiki.openstreetmap.org/wiki/Auto … of_conduct

geri-oc wrote:

M.M. nach sollte so etwas automatisch erfolgen, wenn es geändert wird. Es wurde ja bestehendes nur anders geschrieben.

Eher nicht empfehlenswert, siehe
http://blog.openstreetmap.de/blog/2016/ … streetmap/

Alles gut und schön: Früher habe ich
natural=wood (oder landuse=forest)
wood=deciduous

(richtig, wie im Wiki beschrieben) getaggt.

Dann wurde das verworfen uns soll jetzt

natural=wood
leaf_type=broadleaved
leaf_cycle=deciduous

sein.

Wenn an natural=wood (oder landuse=forest) die Erweiterungen fehlen ist es meldenswert.

@geow:
Ist der Wert aber vorhanden, kann es "automatisch" erfolgen, ohne das Daten "verfälscht" werden.

wood=deciduous -> leaf_type=broadleaved und leaf_cycle=deciduous
wood=mixed -> leaf_type=mixed und leaf_cycle=mixed
wood=coniferous -> leaf_type=evergreen und leaf_cycle=needleleaved (Ausnahme: Lärche wie von Sven genannt)

geri-oc wrote:

wood=coniferous -> leaf_type=evergreen und leaf_cycle=needleleaved

Ich glaub du hast da was verdreht.

geri-oc wrote:

wood=coniferous -> leaf_type=evergreen und leaf_cycle=needleleaved

leaf_type=needleleaved leaf_cycle=evergreen

Solche schnell mal vorkommenden Vertauschungen führen bei automatischen Edits zu großflächigem Murks. 🙂

Diese Vertauschungen sind beim erstellen des Beitrages entstanden. Wird mit Editor editiert, sollte es nicht passieren,also nicht schnell mal vorkommenden Vertauschungen.

Das "Problem" von wood=coniferous wäre somit richtiggestellt - ändert aber nach wie vor nichts an "Vereinheitlichung bei Änderungen" - Noch ist beides möglich: erschwert die Auswertung, gibt Probleme beim rendern, ....

geri-oc wrote:

@geow:
Ist der Wert aber vorhanden, kann es "automatisch" erfolgen, ohne das Daten "verfälscht" werden.

Nein - eben nicht: Es geht beim Editieren nicht nur darum, Daten nicht zu verfälschen, sondern auch falsches Tagging richtig zu stellen. Ein automatischer Edit wäre nur denkbar unter der Voraussetzung, dass die vorhandenen Daten (deciduous, mixed, coniferous und wood vs forest) korrekt sind, was du verständlicherweise aber nicht unterstellen kannst, weitere Erläuterungen siehe http://blog.openstreetmap.de/blog/2016/ … streetmap/

Garmin-User wrote:

Solche schnell mal vorkommenden Vertauschungen führen bei automatischen Edits zu großflächigem Murks. 🙂

Nicht-automatisch führt das halt auch zu kleinflächigem Murks, bzw. das alte Tagging bleibt wegen Aufwand bestehen.

Automatische Edits (sauber ausgeführt!) haben auch Vorteile. Ich erinnere an Wall-E.

Falsche Daten werden durch Auto-Edits nicht besser, aber auch nicht schlechter.

geow wrote:

Nein - eben nicht: Es geht beim Editieren nicht nur darum, Daten nicht zu verfälschen, sondern auch falsches Tagging richtig zu stellen.

Genau so meine ich es, wo die alte (kompletten) Taggingdaten vorhanden sind -> übertragen in neue.
Wo natürlich bei forest oder wood "Spezialisierung" fehlen, kann auch nichts "automatisch" neu gemacht werden.

geow wrote:

Ein automatischer Edit wäre nur denkbar unter der Voraussetzung, dass die vorhandenen Daten (deciduous, mixed, coniferous und wood vs forest) korrekt sind, was du verständlicherweise aber nicht unterstellen kannst, weitere Erläuterungen siehe http://blog.openstreetmap.de/blog/2016/ … streetmap/

Es geht auch nur um diese Daten, die schon "nach dem alten Prinzip" korrekt sind -> diese ins neue zu übertragen - was ich händisch vor Ort mache. Aber siehe einmal:

http://keepright.ipax.at/report_map.php … w_tmpign=0

Und nun nach Bayern oder Schwarzwald verschieben -> aktualisieren -> wieder hunderte "Fehler" - oder schaue bei dir vor Ort.

Wo natürlich "nur" natural=wood oder landuse=forest steht kann eine Fehlermeldung sinnvoll zum "spezialisieren" sein.

Ein anderes Beispiel - aber weitaus weniger "Fehler" - :

This Way uses deprecated tag 'power_source=photovoltaic'. Please use "generator:source=*" instead!

Gegenbeispiel:
This Way uses deprecated tag 'landuse=farm'. Please use "landuse=farmland or landuse=farmyard" instead!
oder:
This Node uses deprecated tag 'noexit=no'. Please use "fixme=Continue" instead!

Hier kann natürlich nur eine Prüfung vor Ort weiterhelfen.

Es geht m.E. nach um mehr Beachtung der "Qualitätsischerung". Wenn solche offentsichtlich richtige "Fehler" automatisch behoben werden, kann man seine "Gegend" einfacher "sauberhalten". So sitze ich 20 Minuten an 20 Waldstücken, nur um die neuen Attribute einzutragen.

So meinte ich es und nun schönes WE.

Nun unter josm geht sowas doch per Filter semiautomatisch. Da hast Du dann immer noch die Kontrollera.

Kann jemand auf deutsch zusammenfassen, was sich geändert hat?

geri-oc, ich bin ganz bei dir. Durch dieses klein-klein, jeder ändert per Hand überholte Tags bindet viel zu viele Ressourcen. Allerdings finde ich, dass die mechanischen edits nicht einzelne User machen sollten, sondern eine ofizielle Gruppe dies sammeln und abarbeiten sollte. Dies verhindert Fehler bei der Beachtung der Richtlinien, Fehler beim Ausführen der Änderung und es kann automatisch jeden Monat der Datenbestand überprüft werden. Wenn dann falsche Taggings neu hinzukommen, kann halb-automatisiert eine informative Nachricht an den Benutzer gesendet werden. Kann ja sein, dass man das alte Tagging noch im Kopf oder in shortcuts gespeichert hat. Wenn die mechanischen Edits zentral geregelt sind, ist die Hürde für Verbesserungen viel kleiner. Nicht zuletzt wäre das Auswerten der Daten viel leichter, weil nicht alle alten Taggings und falschen Schreibweisen ebenfalls beachtet werden müssen. Kostet Zeit/Ressourcen bei der Datenbankabfrage und viel Zeit bei der Suche nach allen in frage kommenden Tags.

geri-oc wrote:

wood=coniferous -> leaf_type=evergreen und leaf_cycle=needleleaved (Ausnahme: Lärche wie von Sven genannt)

Wie willst du bei einer automatischen Änderung wissen, ob das ursprüngliche wood=coniferous ein Lärche bezeichnet oder nicht? Daher ist diese Änderung so nicht sicher durchführbar.

geri-oc wrote:

wood=deciduous -> leaf_type=broadleaved und leaf_cycle=deciduous

Gleiches Problem mit den Lärchen. So auch nicht sicher durchführbar.

geri-oc wrote:

wood=mixed -> leaf_type=mixed und leaf_cycle=mixed

Hier kann man auch nicht wissen, ob der ursprüngliche Mapper mit wood=mixed den Blatttyp oder den Blattzyklus oder beides meinte. So auch nicht sicher durchführbar.

leaf_cycle kann man nicht aus wood=* ableiten.
Aber bei leaf_type sollte das doch problemlos gehen, weil es nur ein anderer Tagname für die selbe Eigenschaft ist!?

Also erst mal bin ich der Ansicht, daß die ganze Umtaggerei völlig überflüssig ist.

Aber wenn's denn schon sein muß sollte es manuell und unter Überprüfung der tatsächlichen Verhältnisse erfolgen, damit es wenigstens zu einer Verbesserung der Daten führt.

bye, Nop

geri-oc wrote:

Es ist ja nun einiges beim taggen von Wald / Forst geändert wurden.

wegavision wrote:

Kann jemand auf deutsch zusammenfassen, was sich geändert hat?

Das Tagging zu Blattzyklus (leaf_cycle) und Blatttyp (leaf_type) von Bäumen und Sträuchern ist seit mehr als 2 Jahren akzeptiert 🙄 und in allen relevanten Editoren per Vorlage verfügbar. 😉

http://wiki.openstreetmap.org/wiki/DE:Key:leaf_cycle
http://wiki.openstreetmap.org/wiki/DE:Key:leaf_type

Lt. Wiki zu leaf_type ist automatisches Ändern ausdrücklich unerwünscht, außer man beachtet die allseits bekannten Grundsätze
http://wiki.openstreetmap.org/wiki/Auto … of_conduct

HalverHahn wrote:

leaf_cycle kann man nicht aus wood=* ableiten.
Aber bei leaf_type sollte das doch problemlos gehen, weil es nur ein anderer Tagname für die selbe Eigenschaft ist!?

Nein, auch das geht nicht per mech Edit, weil du nicht weißt, ob der ursprüngliche Mapper das inhaltlich korrekt erfasst hat.

HalverHahn wrote:

Durch dieses klein-klein, jeder ändert per Hand überholte Tags bindet viel zu viele Ressourcen.

-1
Dieses "klein-klein" und "per Hand" ist unser Alleinstellungsmerkmal! Kein anderer Kartenanbieter verfügt über "Craftmapper" mit so detailliertem Vor-Ort-Wissen wie wir bei OSM.

geow wrote:

HalverHahn wrote:

leaf_cycle kann man nicht aus wood=* ableiten.
Aber bei leaf_type sollte das doch problemlos gehen, weil es nur ein anderer Tagname für die selbe Eigenschaft ist!?

Nein, auch das geht nicht per mech Edit, weil du nicht weißt, ob der ursprüngliche Mapper das inhaltlich korrekt erfasst hat.

Wie bitte? Soll ich davon ausgehen, dass alle Daten in OSM falsch sind? Das kanns doch nicht sein. Das oben vorgeschlagene ist nur das Ändern eines alten in einen neuen Tag. Also inhaltlich von falsch nach richtig. Wenn das früher schon nicht, oder auch neuerdings nicht mehr Wald o.ä. ist, dann wäre beides falsch, nur die der alte Tag sogar doppelt-falsch. Selektieren kann man das deshalb noch lange nicht. Was nützt es dir, wenn Millionen Objekte mit unterschiedlichen Tags für ein und die selbe Objektart/-eigenschaft in der db rumschwirren? Sorry, für mich ist das völlig sinnbefreit.

HalverHahn wrote:

Wie bitte? Soll ich davon ausgehen, dass alle Daten in OSM falsch sind?

Das habe ich nicht pauschal behauptet, oder? Zurück zum Wald: Da in den letzen Jahren zunehmend bessere Satelliten- und Orthofotos zur Verfügung stehen, ist es nicht unwahrscheinlich, dass sowohl der Flächenumgriff als auch die Baumartenzusammensetzung genauer erfasst werden können als bisher. Neben dem aktuellen wiki-konformen Tagging sind die Daten daher auch fachlich und räumlich zu prüfen und ggf. anzupassen.

HalverHahn wrote:

Das kanns doch nicht sein. Das oben vorgeschlagene ist nur das Ändern eines alten in einen neuen Tag. Also inhaltlich von falsch nach richtig. Wenn das früher schon nicht, oder auch neuerdings nicht mehr Wald o.ä. ist, dann wäre beides falsch, nur die der alte Tag sogar doppelt-falsch.

Richtig, wenn du das neue Tagging auf invalide Daten anwendest, wird es dadurch nicht richtig, sondern maskiert nur die vorhandenen Fehler.

Wald wird nie so detailiert gemappt werden. Dann müssten wir schon einzelne Sektionen (Hagen) mappen und die sind meist auch nicht "rein". Auch den Spezialfall "reiner Lärchenwald" gibt es m.E. nicht, zumindest in den bisher gemappten (und mir bekannten) Wäldern.

Wenn ich ein "neues" System einführe, sollte das "alte" nach einiger Zeit ausgedient haben und dann auch entfernt werden.
Leider ist es so, das keine "Klarheiten" geschaffen werden - siehe auch ÖPVN, wo verschiedene Versionen (nebeneinander) bestehen.

wood=coniferous - Nadelwald (ist Lärche ein Nadelbaum oder ein Laubbaum?)
wood=deciduous - Laubwald
wood=mixed - Mischwald. Wenn der Wald aus Nadel- und Laubbäumen besteht, dann ist mixed das Richtige.

Na gut - erledigt - OSM ist nun einmal so ...

... zu deiner Beruhigung: Alle mir bekannten (und halbwegs aktuellen) Renderer berücksichtigen sowohl die alte, als auch die neue Taggingvariante. Der Fehler bei Nichtberücksichtigung ist einfach zu groß. Dennoch sollte man eine Vereinheitlichung anstreben. Dies ist nur automatisiert erfolgversprechend. An dieser Stelle müßten m.E. die recht schwachen Argumente der Bedenkenträger zurücktreten.

Gruß Klaus

geri-oc wrote:

Wald wird nie so detailiert gemappt werden. Dann müssten wir schon einzelne Sektionen (Hagen) mappen und die sind meist auch nicht "rein". Auch den Spezialfall "reiner Lärchenwald" gibt es m.E. nicht, zumindest in den bisher gemappten (und mir bekannten) Wäldern.

Oh doch... wird es, weitaus detaillierter sogar... (Ok, sicher nicht in OSM, allgemein schon). Schau dir mal mal die CIR-Kartiereinkeiten an: http://www.mlul.brandenburg.de/lua/kart … n_2009.pdf (89 Seiten). Wenn die entsprechenden Luftbilder zur Verfügung stehen, ist das möglich. Vergleiche auch: http://www.umwelt.sachsen.de/umwelt/dow … n_2005.pdf

Ok, diese Auswertung haben Profis gemacht. Aber selbst ein ungeübtes Auge kann bestimmte Waldstrukturen mit ein bisschen Übung unterscheiden, verbunden mit Gebietskenntniss...

geri-oc wrote:

Wenn ich ein "neues" System einführe, sollte das "alte" nach einiger Zeit ausgedient haben und dann auch entfernt werden.
Leider ist es so, das keine "Klarheiten" geschaffen werden - siehe auch ÖPVN, wo verschiedene Versionen (nebeneinander) bestehen.

wood=coniferous - Nadelwald (ist Lärche ein Nadelbaum oder ein Laubbaum?)
wood=deciduous - Laubwald
wood=mixed - Mischwald. Wenn der Wald aus Nadel- und Laubbäumen besteht, dann ist mixed das Richtige.

Na gut - erledigt - OSM ist nun einmal so ...

Na, selbstverständlich ist die Lärche ein Nadelbaum!

Hier mal eine meiner visuellen Referenzflächen: https://binged.it/2d0X9VM

südlich des in Ost-West-Richtung verlaufenden Weges: Kiefernforst
nördlich dieses Weges im Westteil: Kiefernforst,
nördlich dieses Weges im Ostteil: direkt am Weg angrenzend: Lärchenforst, (feine lineare und deutlich hellere Baumstruktur), dann dörtdlich davon Mischwald aus Kiefer, Eiche, ect...
am östlichen Rand grenzt ein reiner Laubmischwald an, teils quellig, mit Stieleiche, Erle evt. Esche, Birke ect...

Mein Fazit ist: in unseren Mitteleuropäischen Breiten ist eine Unterscheidung im Luftbild nach Laub-Nadel-Mischwald mit ein klein wenig Übung ohne weiteres machbar, natürlich vorrausgesetzt, man hat auch Gebietskenntnis. Hat übrigens teilweise auch den Effekt, daß übermäßig riwsige Waldpolygone gelegentlich verkleinert werden.

Meine Erfahrung ist aber auch, daß man mit den in OSM verfügbaren Luftbildern nicht immer ein Mischwald erkennt, vor allem nicht, wenn die neue Laubwaldgeneration von der Nadelwaldgeneration überdeckt wird.

Die Erfassung in OSM spiegelt hier aber nicht die Reale Situation vor Ort wider (noch nicht).

Sven

geow wrote:

HalverHahn wrote:

Wie bitte? Soll ich davon ausgehen, dass alle Daten in OSM falsch sind?

Das habe ich nicht pauschal behauptet, oder? Zurück zum Wald: Da in den letzen Jahren zunehmend bessere Satelliten- und Orthofotos zur Verfügung stehen, ist es nicht unwahrscheinlich, dass sowohl der Flächenumgriff als auch die Baumartenzusammensetzung genauer erfasst werden können als bisher. Neben dem aktuellen wiki-konformen Tagging sind die Daten daher auch fachlich und räumlich zu prüfen und ggf. anzupassen.

Wenn die Wälder ungenau sind, dann sind auch die Straßen, Flüsse, Felder, Siedlungen, Häuser, etc. ungenau. Willst du neben dem dem Wald-tagging überall die anderen Objekte graderücken? Wie lange würde das dauern? Wieviel neues könnte dafür in die Datenbank eingetragen werden? Was ist mit den Wäldern, die kein wood=* hatten? Sollen die deswegen möglicherweise falsch bleiben? Wenn du die Ausdehnung des Waldes verbessern möchtest, solltest du besser alle Waldpolygone untersuchen, nicht nur die mit wood-tag (um nur beim Wald zu bleiben...). Von daher ist das kein Grund, ein veraltetes Tag nicht anzupassen.

Ich habe ja nichts dagegen, wenn jeder Baum (detailliert) oder jede Sektion (detailliert) gemappt werden.
Aber in OSM ist ein Wald einschließlich Straßen, Flüsse, Wege eine größere Fläche mit Wiesen und Teichen. Wenn du es einmal so detailliert mappen möchtest ...

http://www.openstreetmap.org/relation/5455538

Und der Wald ist nur ein Forst ohne Detaillierung - also nach altem System fehlt mindestens wood=mixed erst einmal. Wie würdes du es nach dem neuen System mappen?

landuse=forest, wood=mixed -> landuse=forest, leaf_type=mixed und leaf_cycle=mixed

Wäre doch (vorerst) eine richtige Entscheidung, bis du den Laubwald und den Lärchenwald aus dem großen Wald löst und spezialisierst.

Das alles löst aber nicht die neben einander bestehenden Mappingarten (zumindest nicht in den nächsten Jahren).

geri-oc wrote:

Wie würdes du es nach dem neuen System mappen?

Wirst du gleich sehen.... ich kenne diese Ecke einigermaßen gut... Ich bin da gerade gerade dran...

Grundsätzlich bin ich der Meinung, daß wir (so ziemlich) alle nötigen Tags haben und wir diese anwenden sollten. Wir sollten uns auch davon lösen, bei den Landuse-Tags zu sehr zu generalisieren.

Sven

HalverHahn wrote:

Wenn die Wälder ungenau sind, dann sind auch die Straßen, Flüsse, Felder, Siedlungen, Häuser, etc. ungenau.

Du bist noch nicht lange dabei oder?
Die Wälder aus der Frühzeit von OSM kamen aus anderen Quellen als die Straßen und ähnliche Objekte. Vielfach waren die Landsat Satellitenbilder die einzigen vorhandenen Luftbilder. Straßen konnte man auf den Bildern nicht erkennen, als wurde für letzteres auf GPS tracks zurückgegriffen. Wälder hat man aber von Landsat abgemalt, auch wenn durch die mangelnde Auflösung der Waldrand auch mal um 50 Meter daneben war. Die darauf folgenden Luftbilder von Yahoo waren auch meist nicht soo toll (so sie in der jeweiligen Gegend vorhanden waren), sehr oft wurde der Schatten des Waldes auf dem angrenzenden Acker mit zum Wald gehörend gemappt. Und bei vielen auch später gemappten Wäldern habe ich den Eindruck, wood=mixed wurde nur ergänzt, damit das tag nicht leer bleibt. Das ist ja höchstens zur Hälfte falsch. Das zusätzliche Problem des Versatzes ist auch bei den Bing-Bildern nicht gelöst. Bis vor einige Wochen war ich persönlich der Meinung, daß die Bing-Bilder hier in D zwar einen Versatz haben können, aber der üblicherweise unterhalb der Genauigkeit der hochgeladenen GPS-tracks ist. Nordöstlich Neustadt am Rübenberge war und ist die Lagegenauigkeit von Bing aber grottig, und das, obwohl die Gegend platt wie ein Pfannkuchen ist - die einzigen Erhebungen dort waren vermutlich mal inzwischen abgetorfte Hochmoore.
Wenn ein Mapper feststellt, daß die angrenzende Straße im Norden einige 10 Meter Versatz nach Norden hat und die im Süden ebensoviel nach Süden, dann nehme ich an, daß er jegliche Lagekorrektur aufschiebt, bis es dermaleinst mal Luftbilder gibt, mit denen sich das zumindest widerspruchsfrei erledigen läßt.

Baßtölpel

geri-oc wrote:

Und der Wald ist nur ein Forst ohne Detaillierung - also nach altem System fehlt mindestens wood=mixed erst einmal. Wie würdes du es nach dem neuen System mappen?

landuse=forest, wood=mixed -> landuse=forest, leaf_type=mixed und leaf_cycle=mixed

Also in meiner Umgebung bin ich schon vor einiger Zeit entsprechende Bereiche durchgegangen und habe alte wood-Tags nach meiner Luftbilderfahrung in meiner Gebietskenntnis geändert... Im Zweifelsfall habe ich mit die Ecke gemerkt und bin das mal abgefahren... Teilweise habe ich auch OverpassTurbo genutzt, um die letzten kleinen Flecken im Spreewald zu identifizieren... Aber alles Handarbeit, verbunden mit Gebietskenntniss... In anderen, mir nicht bekannten Landstrichen würde ich das nicht machen.

Übrigens Feuchtwiesen Atterwasch habe ich fertig: http://www.openstreetmap.org/#map=15/51 … 8&layers=N

Das dürfte der Situation, wie ich sie nach mehrmaligem Besuch gesehen haben entsprechen.

Sven

@Basstoelpel: Ja, aber das spricht doch eher dafür alle Wälder zu untersuchen, anstatt die nur die mit wood=*, oder etwa nicht? Sollen deswegen über Jahre hinweg veraltete Tagdaten in der db eingetragen bleiben? Bei jeder Auswertung müssen dann gleich mehrere Schlüssel abgefragt werden. Und vor alledem müssen dem Auswertet erstmal alle möglichen Kombinationen bekannt sein. Immernoch ein sehr, sehr schwaches Argument.

@gerioc: Das geht doch... Ist doch nicht so viel, 4 MB-Daten sind überschauber. Ich hab da mal was auf die Schnelle in Overpass Turbo gebaut:

http://overpass-turbo.eu/s/iyP

1. Abgefragt wird das Land Sachsen.
2. Abgefragt wird wood=*
3. Es bedeuten:

blau: wood=mixed
rot: wood=deciduous
schwarz: wood=coniferous

grün: alle anderen Werte mit wood='irgendwas'

Elemente ohne wood werden ignoriert, da ich erst mal überlegen muß, wo wood=* überall drin sein könnte, das wäre eine mögliche nächste Fehlerprüfung.

Im Moment fallen mir als mögliche Basiswerte ein: tree=*, tree_row=*, landuse=forest, natural=wood, natural=scrub, natural=wetland+wetland=swamp

Sven

streckenkundler wrote:

@gerioc: Das geht doch... Ist doch nicht so viel, 4 MB-Daten sind überschauber. Ich hab da mal was auf die Schnelle in Overpass Turbo gebaut:

http://overpass-turbo.eu/s/iyP

1. Abgefragt wird das Land Sachsen.
2. Abgefragt wird wood=*
3. Es bedeuten:

blau: wood=mixed
rot: wood=deciduous
schwarz: wood=coniferous

grün: alle anderen Werte mit wood='irgendwas'

Elemente ohne wood werden ignoriert, da ich erst mal überlegen muß, wo wood=* überall drin sein könnte, das wäre eine mögliche nächste Fehlerprüfung.

Im Moment fallen mir als mögliche Basiswerte ein: tree=*, tree_row=*, landuse=forest, natural=wood, natural=scrub, natural=wetland+wetland=swamp

Sven

Irgendwie reden wir nicht vom selben. Es geht um das (automatische - weil durch neue Schlüssel und Attribute festgelegte) ändern von zum Beispiel

landuse=forest, wood=mixed -> landuse=forest, leaf_type=mixed und leaf_cycle=mixed (automatisch).

Dabei sollten keine Fehler entstehen.

Anders ist das Beispiel mit der Lärche, die "alt" auch unter wood=coniferous geführt wird. Sie ist schon immer ein Bestandteil eine Nadelwaldes (wenn nicht eines Mischwaldes). Dort den "alten" Nadelwald in in "neuen" Nadelwald ändern führt natürlich zu "geringen" Fehlern. Dort müsste dann aber der Nadelwald wiederrum zum gemischten Wald werden, da ja die Lärche eine Nadelbaum ist, aber gegenüber der Fichte/Tanne die Blätter abwirft.

Im Prinzip können wir alle Wälder als "neue Mischwälder" mappen, solange nicht nach einzelnen Sektionen mit Baumarten gemappt wird. Und selbst in einer "Lärchensektion" sind Birken ...

Mit dem "automatischen Ändern" der alten in die neue Form, wäre das Problem "alter Schlüssel" erst einmal erledigt.
Es wird dann nur noch nach em "neuen Schlüssel" eingetragen (eventuell auf kleine Sektionen - früher Hagen mit Nummer - verkleinert) und kann auch so "einfach" ausgewertet werden.

geri-oc wrote:

landuse=forest, wood=mixed -> landuse=forest, leaf_type=mixed und leaf_cycle=mixed (automatisch).

Dabei sollten keine Fehler entstehen.

Doch, dabei können Fehler entstehen.

Lärchen + Buchen: wood=mixed -> leaf_type=mixed, aber leaf_cycle=deciduous

Wenn man sich nur auf Deutschland beschränkt, dann wären nach bisherigen Informationen hier im Forum nur diese Umwandlung fehlerfrei:
wood=deciduous -> leaf_type=broadleaved + leaf_cycle=deciduous* (Achtung: siehe unten)
wood=coniferous -> leaf_type=needleleaved (ohne leaf_cycle)
wood=mixed -> leaf_type=mixed (ohne leaf_cycle)

Da es hier uns unbekannte Exoten gibt, würde ich leaf_cycle=* in jedem Fall weglassen, weil dessen Richtigkeit nicht sichergestellt ist. Zum Beispiel hat der Ilex Blätter, wirft sie aber im Winter nicht ab, sondern ist immergrün. Demnach bitte nur die veralteten wood=* gegen entsprechende leaf_type=* austauschen.

geri-oc wrote:

streckenkundler wrote:

@gerioc: Das geht doch... Ist doch nicht so viel, 4 MB-Daten sind überschauber. Ich hab da mal was auf die Schnelle in Overpass Turbo gebaut:

http://overpass-turbo.eu/s/iyP

1. Abgefragt wird das Land Sachsen.
2. Abgefragt wird wood=*
3. Es bedeuten:

blau: wood=mixed
rot: wood=deciduous
schwarz: wood=coniferous

grün: alle anderen Werte mit wood='irgendwas'

Elemente ohne wood werden ignoriert, da ich erst mal überlegen muß, wo wood=* überall drin sein könnte, das wäre eine mögliche nächste Fehlerprüfung.

Im Moment fallen mir als mögliche Basiswerte ein: tree=*, tree_row=*, landuse=forest, natural=wood, natural=scrub, natural=wetland+wetland=swamp

Sven

Irgendwie reden wir nicht vom selben. Es geht um das (automatische - weil durch neue Schlüssel und Attribute festgelegte) ändern von zum Beispiel

landuse=forest, wood=mixed -> landuse=forest, leaf_type=mixed und leaf_cycle=mixed (automatisch).

Dabei sollten keine Fehler entstehen.

Doch ich weiß schon, was du willst... Die Masse der Mapper, mich eingeschlossen, wollen aber keinen automatischen Edit.
Bei deinem Beispiel kann ein Fehler entstehen...

wood=mixed sagt meiner Ansicht nach nur aus, daß der Wald gemischt ist...

Nur mit leaf_type und mit leaf_cycle hast du die Möglichkeit, bestimmte Waldformen zu beschreiben... Wenn du z.B. einen Fichtenwald mit Mischbaumart Lärche hast, war das früher wood=coniferous. Neu ist es nun leaf_type=needleaved + leaf_cycle=mixed.
Du kannst z.B. auch ein Lärchenforst, mit Laubholz haben (Stichwort Waldumbau)... früher: wood=mixed, jetzt leaf_type=mixed + leaf_cycle=deciduous.

Das lässt sich nicht mit ruhigem Gewissen automatisch ändern. Das Bedarf eine gewissen Vor-Ort-Kontrolle, verbunden mit Gebietskenntnis.

Mit der Overpass-Abfrage kannst du aber die paar Flächen manuell durchgehen und entsprechend Luftbild wood in leaf_type/leaf_cycle ändern...

So habe ich das in der Umgebung des Spreewaldes gemacht...

Sven

Leicht OT: http://www.tagesschau.de/inland/fichte-101.html

dürfe langfristig das Tagging beeinflussen. 😉

Gruss
walter

wambacher wrote:

Leicht OT: http://www.tagesschau.de/inland/fichte-101.html

dürfe langfristig das Tagging beeinflussen. 😉

Gruss
walter

[halbOT]

Ach die Forstwissenschaftler... 😐

Viele suchen doch nur Möglichkeiten, Monokulturen weiter als einzig Richtiges zu begründen, ohne auf ökologische Folgen zu schauen... Ich kenne die Monokultur-Disskussion mit den Grünbejackten im Spreewald... Hinreichend gemischte Wälder mit gebietsheimischen Gehölzen dürften auch mittel- bis langfristig klimawandelresistent sein...

Wer sich über den Waldzustand informieren will: http://www.forstwirtschaft-in-deutschla … dsbericht/

[/halbOT]

Sven

Versuch einer Zusammenfassung:
Das wichtigste Argument gegen einen automatischen Edit ist die Tatsache, dass räumliche und fachliche Fehler von Wald/Forstflächen, die bei der Ersterfassung mangels guter Hintergrundbilder unvermeidlich waren, nicht beseitigt und sogar maskiert werden. Mit Einführung der neuen Tags leaf_type und leaf_cycle im Juni 2014 sind diese unmittelbar massiv verwendet worden. Die relativ geringe Anzahl von Objekten nach altem Schema sollte schon deshalb manuell und mit Vor-Ort-Kenntnis geändert werden, weil das überwiegend "Karteileichen" sein dürften, die auf Basis von Landsat und Yahoo-Bildern erfasst wurden.

Grafik lt. http://taghistory.raifer.tech/

Sehr interessant - und danke für den link. Die Sprünge in wood=mixed finde ich ausgesprochen verdächtig.

Baßtölpel

edit: Nachtrag: leider kann man nicht sehen, wieviel durch die Lizenzumstellung verloren gegangen ist - auch die Anzahl der früher vorhandenen tags ist den redaction bot zum Opfer gefallen. Merkwürdigerweise hat im Spätsommer 2012 nur die Zahl der Mischwälder wieder zugenommen.

Basstoelpel wrote:

Die Sprünge in wood=mixed finde ich ausgesprochen verdächtig.

Positive senkrechte Sprünge dürften Importe sein, negative senkrechte Änderungen (semi)automatische Edits - beides auf regionaler Ebene.

Ich war jetzt länger nicht mehr dabei. Doofe Frage: sollen jetzt Waldflächen aufgeteilt werden, wenn man jetzt mittendrin andere Baumarten hat? Klar nicht für jeden Baum..meine nur, wenn sich das jede paar hundert Meter ändert. D.h. ein Gebiet von 5 km² von einer Fläche zu 20, 30, 50 Flächen aufteilen? Oder wie genau wird bzw. soll das gemacht werden?

@HalverHahn veraltetes Taging ist nicht "falsch" sondern nur veraltet.

Typischerweise werden neue Taging Schema eingeführt wenn die bestehenden zu wenig ausdruckstark sind (Tags umbennen etc. gibt es zwar auch hin und wieder, dass ist fast immer IMHO Blödsinn). Bei der Neuerfassung und Pflege der Daten kann dann mehr Information festgehalten werden.

Bei einem automatischen Edit steigt der Informationsgehalt der Daten per Definition nicht und deshalb gibt es ausser übertriebenen Ordnungsinn keinen Grund in diesem Fall einen zu machen. Schlussendlich müssten auch noch alle so umgetaggten Objekte für eine Überprüfung markiert werden, was sie aber jetzt schon sind.

@seichter an was du dich anscheinend nicht errinnerst ist den Aufwand und Zeit die damals in Wall-E gesteckt wurde.

SimonPoole wrote:

Bei einem automatischen Edit steigt der Informationsgehalt der Daten per Definition nicht und deshalb gibt es ausser übertriebenen Ordnungsinn keinen Grund in diesem Fall einen zu machen.

Doch es gibt Gründe:
1) Tagwildwuchs verringern
2) Auswertung vereinfachen

Wie ist denn der Status quo:

Auswertungen müssen derzeit:
landuse=farm UND farmland
amenity=fire_hydrant UND emergency=fire_hydrant
wood=* und leaf_type
power=substation UND power=sub_station
etc. pp. beachten.

SimonPoole wrote:

@seichter an was du dich anscheinend nicht erinnerst ist den Aufwand und Zeit die damals in Wall-E gesteckt wurde.

Was ist daraus geworden? Die Quellen wurden nie veröffentlicht (angeblich wohl, um Missbrauch zu verhindern), weder Oli-Wan noch Wall-E sind noch aktiv. Topp!

AlphaRay wrote:

Ich war jetzt länger nicht mehr dabei. Doofe Frage: sollen jetzt Waldflächen aufgeteilt werden, wenn man jetzt mittendrin andere Baumarten hat? Klar nicht für jeden Baum..meine nur, wenn sich das jede paar hundert Meter ändert. D.h. ein Gebiet von 5 km² von einer Fläche zu 20, 30, 50 Flächen aufteilen? Oder wie genau wird bzw. soll das gemacht werden?

Ich meine nein... es muß nicht zwangsläufig aufgeteit oder fragmentiert werden.

Aber:
Wenn z.B. eine bewaldete Fließgewässerrinne (Laubwald oder Bruchwald) sich mitten durch ein Kiefernforst zieht, sollte man schon den Wald aufteilen...

z.B. Dahmetal bei mir und die Ecke ist ein Beispiel, wo das noch nicht gemacht ist:

http://mc.bbbike.org/mc/?lon=13.724155& … te&marker=

Hier die angesprochenen Feuchtwiesen Atterwasch, vorher war einfach ein Waldpolygon, wi der Schenkendöberner See ausgestanzt war:

http://mc.bbbike.org/mc/?lon=14.605411& … te&marker=

Sven

Ah..ok. Danke 🙂 Hab Lust ein wenig was zu machen..seit ich damals Höxter überarbeitet habe, ist kaum was in der Gegend passiert, bis auf alle Häuser mit Hausnummern. Da ich wieder mit MTB anfangen wollte, kann ich neben den Waldpfaden auch die Wälder selbst mal anpassen.
Was ist denn heute gängig? Sind das innere Polygone, oder werden die alten aufgesplittet? Gelöscht? Zusammengefügt an den Kanten oder einzeln gelassen?

AlphaRay wrote:

Was ist denn heute gängig? Sind das innere Polygone, oder werden die alten aufgesplittet? Gelöscht? Zusammengefügt an den Kanten oder einzeln gelassen?

Also ich arbeite stets mit geschlossenen Linienzügen. Allzugroße Polygonverschachtelungen vermeide ich nach bestem Wissen und gewissen. Vielfach lassen sich auch MP's ganz vermeiden, dann sind es einfache geschlossene Linienzüge.
vorhandene große Polygone zerteile ich, ggf. ergeben sich neue MP-Relationen.

Sven

chris66 wrote:

Doch es gibt Gründe:
1) Tagwildwuchs verringern

Der ist generell klein und den kann man auch, zum Beispiel, wie in diesem Fall, die Objekte effektiv pflegt (was eh viel zu wenig passiert) verhindern.

2) Auswertung vereinfachen

Wie ist denn der Status quo:

Auswertungen müssen derzeit:
landuse=farm UND farmland
amenity=fire_hydrant UND emergency=fire_hydrant
wood=* und leaf_type
power=substation UND power=sub_station
etc. pp. beachten.

Es gibt noch eine Handvoll mehr, dass ist es aber dann auch. Auch wenn darüber gestönt wird, keine wirklich grosse Bürde, definitiv kleiner als was man für andere Taggingvarianten treiben muss. Das liegt natürlich daran, dass realtiv selten nicht rückwärts kompatible Schema effektiv umgesetzt werden (und substation vs. sub_station war natürlich ein Witz).

chris66 wrote:

landuse=farm UND farmland

Gerade bei diesem Beispiel kommt man um eine manuelle Bearbeitung jedes einzelnen landuse=farm nicht drum herum. Ich habe da vor einiger Zeit bei mir in der Gegend mal etwas aufgeräumt (geht in den meisten Fällen gut vom bing Luftbild abzuleiten) und war erstaunt, wie viele landuse=farm eben nicht landuse=farmland sind, sondern landuse=farmyard.

chris66 wrote:

Doch es gibt Gründe:
...
2) Auswertung vereinfachen

Wie ist denn der Status quo:

Auswertungen müssen derzeit:
...
amenity=fire_hydrant UND emergency=fire_hydrant
...

Und trotzdem wird es auch 2025 noch "Nebenberufsmapper" geben, die mit ihren 2010 gelernten Tags weiterarbeiten, weil sie nicht mehr ins Wiki, ins Forum oder in Mailinglisten schauen.

Deswegen sehe ich "neue" Tags sehr kritisch. Landuse=farm zu farmland und farmyard aufzuspalten war aus Klarstellungsgründen sinnvoll. Das mit dem Hydranten habe ich nicht verfolgt (die interessieren mich nicht), aber irgendwie kommt es mir sehr akademisch vor.

chris66 wrote:

amenity=fire_hydrant UND emergency=fire_hydrant

Das Thema ist erledigt, da gab's 2015 den Edit.

Es gibt auch noch type=broadleaved/broad-leaved/broad_leaved/needleleaved/mixed.

Die ersten drei scheinen überwiegend Einzelbäume zu betreffen. Im Gegensatz zu meinen Bedenken bei Wäldern würde ich hier einen mechanischen edit befürworten. Die anderen sind abzählbar endlich viele.

Baßtölpel

SimonPoole wrote:

@HalverHahn veraltetes Taging ist nicht "falsch" sondern nur veraltet.

Typischerweise werden neue Taging Schema eingeführt wenn die bestehenden zu wenig ausdruckstark sind (Tags umbennen etc. gibt es zwar auch hin und wieder, dass ist fast immer IMHO Blödsinn). Bei der Neuerfassung und Pflege der Daten kann dann mehr Information festgehalten werden.

Bei einem automatischen Edit steigt der Informationsgehalt der Daten per Definition nicht und deshalb gibt es ausser übertriebenen Ordnungsinn keinen Grund in diesem Fall einen zu machen. Schlussendlich müssten auch noch alle so umgetaggten Objekte für eine Überprüfung markiert werden, was sie aber jetzt schon sind.

@seichter an was du dich anscheinend nicht errinnerst ist den Aufwand und Zeit die damals in Wall-E gesteckt wurde.

Korrekt, veraltetes Taging ist veraltet, aber auch für viele kaum verwertbare Redundanz. Welcher Auswerter, der nicht extrem tief in der OSM-Materie steckt, weiß welche alten Tags noch massenhaft existieren. So macht es jede Auswertung viel komplizierter und unvollständiger.

Für mich ist dieses krampfhafte Festhalten an dem Durcheinander nicht nachvollziehbar. Bisher ist noch kein vernünftiges Argument aufgetaucht, weshalb man die Datenbank aufgeräumt halten soll. Warum müssen (genau) diese Objekte für eine Überprüfung markiert werden? Der Mehrwert am Durcheinander steht in keinem Verhältniss zu einer aufgeräumten Datenbank. Zumal sich alte Objekte auch anders finden lassen, und vor allem auch alle, nicht nur die mit redundanten Tags. Wer bestimmt, was veraltet sein könnte, und ab welchem Datum. Hier vor allem interessant, warum nur die Wälder mit wood-Tag überprüft werden sollen, warum nicht alle Wälder, oder alle Flächen-Objekte? Sollen Jahrzehnte ins Land gehen, bis sich irgendjemand erbarmt, alles maschinentaugliche per Hand zu ändern? Wer sagt, dass nicht einfach jemand nur das alte gegen das neue Tag getauscht hat? Hätte ich vorhin nicht einfach den note=Hydrant ungesehen zum emergency=fire_hydrant ändern dürfen, ohne vor Ort nochmal überprüft zu haben? Sonst muss jemand das note-Tag auffallen + gleichzeitig in der Nähe sein/wohnen + das Objekt vor Ort überprüfen + das richtige Tag wissen.

Schade, dass Wall-E nicht mehr existiert. Die ganze Arbeit die da reingesteckt wurde, nützt für die Zukunft nicht mehr. Deswegen fände ich es sinnvoll, wenn die OSM-Führung eine Abteilung einrichtet, wo sich eine kleine Gruppe um Datenqualität kümmert. So dann dies auf mehrere Schultern verteilt werden und bleibt bestehen wenn einer aus welchen Gründen auch immer wegbricht. Jeder der die Daten auswertet steht vor großen Herausforderungen. Das geht von einfachen Dingen wie Komma statt Punkt in Zahlwerten bis hin zu Tippfehlern. Zum Beispiel oneway:bicycle <-> bicycle:oneway, da sind knapp 1% der Daten "versteckt" und leider für die meisten Auswerter nicht verwertbar. Wenn dann Leute unbedingt die Daten über Jahre versteckt und schlecht-brauchbar halten wollen, dann ist das sehr schade um die tollen Daten.

... dann ist das sehr schade um die tollen Daten.

zum Beispiel auch:

http://keepright.ipax.at/report_map.php … r=75021546

Vielleicht sollte jeder einmal 10 km um seinen Mapperort mit "Qualitätssicherung" (1x im Jahr?) schauen ...