Wald

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

-1

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

Eher nicht empfehlenswert, siehe
http://blog.openstreetmap.de/blog/2016/09/das-problem-mit-mechanischen-edits-in-openstreetmap/

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)

Ich glaub du hast da was verdreht.

leaf_type=needleleaved leaf_cycle=evergreen

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

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, …

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/09/das-problem-mit-mechanischen-edits-in-openstreetmap/

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.

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.

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?schema=101&error=45131728&zoom=10&lat=49.58612&lon=10.80286&layers=B0T&ch=0%2C60&show_ign=0&show_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.

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.

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

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

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

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/Automated_Edits_code_of_conduct

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

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

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.

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.

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