Wald

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

Gruss
walter

[halbOT]

Ach die Forstwissenschaftler… :expressionless:

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-deutschland.de/waelder-entdecken/waldzustandsbericht/

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

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.

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.

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!

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&lat=52.095762&zoom=16&num=2&mt0=mapnik&mt1=bing-satellite&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&lat=51.935487&zoom=15&num=2&mt0=mapnik&mt1=bing-satellite&marker=

Sven

Ah…ok. Danke :slight_smile: 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?

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

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.

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

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.

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.

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

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.

zum Beispiel auch:

http://keepright.ipax.at/report_map.php?schema=101&error=75021546

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