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:
- Tagwildwuchs verringern
- 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:
Hier die angesprochenen Feuchtwiesen Atterwasch, vorher war einfach ein Waldpolygon, wi der Schenkendöberner See ausgestanzt war:
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?
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.
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 …