Laufendes proposal definiert natural=scrub um

Communities Deutschland (Germany)
1

Hier das Proposal mit dem niedlichen Titel https://wiki.openstreetmap.org/wiki/Proposed_features/shrubbery

Als Hauptanliegen wird vorgebracht, dass natural=scrub in der Praxis nicht für “mit Sträuchern oder niedrigen Bäumen bewachsenes unkultiviertes Land” sondern für “Land, auf dem Büsche stehen” verwendet wird. Deshalb wird das “kultiviert oder nicht” in den Schlüssel “maintained” verschoben, ohne dass ein Defaultwert dafür angegeben ist.

Ich kann das insofern verstehen, als die Proponenten aus Holland stammen, und mir scheint, dass dort der Tag natural=scrub ausgiebig dafür verwendet, d.h. missbraucht wird, zB Hecken als Fläche zu erfassen. Andererseits ist das ungerecht allen denen gegenüber, die nach Dokumentation gearbeitet haben, und die nun die, wenn das Proposal durchgeht, fehlende Information nachtragen sollen?

Da wird Informationsverlust produziert. Mit Streetcomplete wird das so um die zehntausend Jahre dauern, das aufholen, in den Städten schneller, am Land langsamer. Wo ich zu Hause bin, da ist die Trefferquote sehr hoch, über 90% nach Dokumentation, im Unterschied zum Forst/Wald Dualismus :wink: Ein mechanical edit den Default nachtragen geht nicht.

Hier Zahlen (Fläche/Anzahl : NL / AT) die zeigen, wie die Verwendung für “scrub” in den letzten Jahren in Holland explodiert ist. Berlin sieht wahrscheinlich genau so aus. Bayern, Baden Württemberg, Sachsen etc, Gegenden in denen es “natural=scrub” in der bestehenden Weise tatsächlich gibt?

2

Wenn das so wäre, kann es dann sein, dass der große Sprung bei der Anzahl Ende 2019 erfolgt ist, nachdem man osm-carto geändert hat und barrier=hedge auch mit area=yes nicht als Fläche gerendert wird?

3

Irgendwo hatte ich noch im Hinterkopf, das es dazu schon mal einen Thread hier gab

4

Nachdem “bewaldete Fläche” jetzt einheitlich natural=wood getaggt wird, ist es dann nicht nur konsequent, natural=scrub genauso aufzufassen?

5

Wo steht dass natural=wood schon durch/usus ist? Im Wiki nicht.

Edit:natural=wood eingefügt zum besseren Verständnis.

6

Also umgetaggt worden ist in Holland jedenfalls nichts. Barrier=hedge hat weder bei der Anzahl noch beim Flächeninhalt einen Knick Ende 2018.

Beispiel, nicht von mir gefunden, aus dem “scrub” Artikel im Wiki, derzeit noch als “kontroversiell” bezeichnet - https://www.openstreetmap.org/#map=19/51.97940/5.67150 - ein wenig verschoben, zwecks https://www.mapillary.com/app/?lat=51.979408171456&lng=5.6715123805739&z=17&pKey=913235809476579&focus=photo

Die Bäume hinter dem Bodendecker “Gebüsch” sind übrigens forstwirtschaftlicher Nutzwald.

Ich fürchte nur, dass durch die Änderung der Definition, die nicht den Status Quo der Definition als Defaultwert übernimmt, die Unklarheit mehr wird, statt weniger. Und ich sehe eher die in der Pflicht etwas nachzutragen, die gegen die Dokumentation gemappt haben, als diejenigen, die sich daran gehalten haben.

7

Ich glaube das Grundproblem ist das die proponenten diese Tagging erweiterung die keys “natural” und “landuse” für micromapping erweitern wollen.

Das halte ich für einen total falschen Weg. Landuse/natural sind dafür gedacht große Gebiete zu klassifizieren und nicht jedes einzelne Beet im Privatgarten zu erfassen.

Flo

8

Argumentationen die auf den Key Bezug nehmen (natural darf nicht man-made sein), gehen am Thema vorbei, denn die gewählten Keys in OSM machen nicht immer Sinn, u.A. weil Tags durch die anarchistische Tag-Findung oft auch wachsen. Bestes Beispiel: highway. Oder eben auch der große Bruder von natural=scrub: natural=wood - wird auch genutzt für Holzplantagen und bewaldete Flächen in Parks.

Grundsätzlich 100% richtig. Wir können keine bestehenden Tags umdefinieren, weil sonst alles/vieles bisher gemappte plötzlich nach Wiki-Definition falsch wäre.

Die Wiki-Definition muss immer erklären, wie der Tag tatsächlich genutzt wird.

Was aber immer geht, ist die Möglichkeit zu geben, weitere Details zu einem Feature hinzuzufügen, beziehungsweise es weiter einzugrenzen.

Das Proposal möchte natürliches Buschland besser von Buschwerk trennen. Die Autoren gehen davon aus, dass es mittlerweile längst usus ist, jegliche Art von Büschen als natural=scrub zu taggen, unabhängig davon, von wem das gepflanzt wurde und wie “wild” es aussieht. Also, wie etwa natural=wood.

Ich denke es ist diese Annahme, die Hungerburg in Zweifel zieht.

Klar ist, dass diese Art von Tagging u.A. wohl in den Niederlanden verbreitet ist. Für andere Regionen sei jeder mal selbst dazu aufgerufen zu schauen wie das bei ihm selbst ist. Dieses Mapping wird in Regionen wo microgemappt wird vermutlich öfter zu finden sein.
Jedoch allein der Fakt dass es für flächiges Buschwerk bisher keinen akzeptierten eigenen Tag gibt, lässt nahe legen, dass der Tag u.A. so genutzt wird.

Zum Schluss will ich noch einmal darauf hinweisen dass dieses Proposal bereits der zweite ist, die Autoren versuchen es mit diesem mit einem Kompromiss.

Der erste (natural=shrubbery) ist ironischerweise u.A. an der Auffassung vieler gescheitert, dass de-facto schon viele Buschwerke als natural=scrub gemappt sind, eine Definition von natural=shrubbery also implizit eine Umdefinition der de-facto Nutzung von natural=scrub bedeuten würde und sowas wollen wir ja vermeiden

Ihr versteht schon die Ironie darin wenn dieser jetzt auch scheitert, und zwar aus dem genau entgegengesetztem Grund, oder?

Es wäre ein Zeugnis dafür, dass die Community nicht imstande ist, mit den derzeitigen Mitteln (Proposals) eine Entscheidung zu treffen. Ohne Entscheidung taggt weierhin jeder wie er will. Es werden also Buschwerke weiterhin “irgendwie” (ohne Subtag) getaggt, was wiederum u.A. weiter die de-facto Definition von natural=scrub verwässert, also wohlmöglich den gegensätzlichen Effekt hat, zu dem was sich die die dagegen gestimmt haben, erhoffen.

9

Genau das hatte ich auch in der Begründung meines Votes geschrieben.

Ich wäre auch eher für natural=shrubbery gewesen. natural=tree_rows sind auch in den seltensten Fällen natürlich entstanden und trotzdem kommt keiner auf die Idee, dass es man_made=tree_row sein sollte… Und wenn dann ein paar natural=scrub zu natural=shrubbery umgetaggt würden, dann würde dort bei manchen Renderern eben eine Zeit lang nichts mehr angezeigt werden, bis sie natural=shrubbery implementieren. Wäre das denn so schlimm gewesen?

Aber damit es überhaupt irgendein dokumentiertes Tagging geben kann, habe ich auch im neuen Proposal mit Ja abgestimmt.

Vielleicht bräuchte es eine erste Abstimmung mit der üblichen 80/20-Mehrheit, die darüber entscheidet, ob es einmalig eine zweite Abstimmung geben soll, in der dann mit einfacher Mehrheit zwischen natural=shrubbery und natural=scrub mit Zusatztags entschieden wird.

10

sehe ich ähnlich,
soweit ich das überblicke, haben die Autoren die Kritik am “alternativen” Haupttag aufgegriffen und wollen nun die Differenzierung auf Subtags legen.
Das ist im Kern die richtige Vorgehensweise, und da klingeln bei mir - anders als beim alten Proposal - auch nicht alle Alarmglocken.

11

Hallo zusammen.

Ich hadere auch mit diesem Proposal sehr…

scrub:density=* ist für mich ein hochgradig subjetiver Tag… es ich in meinen Augen nicht real erfassbar. Es gibt alle Übergänge und keinen Grandmesser, wann welcher Wert anzuwenden ist.

scrub:shape=* verstehe ich dar nicht. … wird nie wirklich auswerbar sein…

maintained=* Je nach dem, was man vorfindet, werden semi, rarely und no auch kaum oder gar nicht unterscheidbar sein… Was ist semi, was ist rarely… Das ist äußerst stark von dem verwendeten Pflanzenmaterial abhängig…

Ich denke bei sowas auch immer an gepflanze Hecken oder gestufte Waldrandstrukturen, die bewusst mit standortgerechten/ standortheimischen strauchigen Gehölzen gepflanzt sind… Diese gibt es recht viel in der Landschaft… richtig gut werden diese in keine der Kategotrien passen…

Insgesamt halte ich das für nicht umsetzbar. Für User mit Detailverliebtheit (Mikromapping) würde das auch Tür und Tor für eine starke Flächenfragmentierung auf einem kleinen Areal öffnen…

Sven

12

Vielleicht wären alle froh, wenn man maintained=no als Default ansetzen würde? Dann müsste wildes Buschwerk nicht umgetagged werden.

Ansonsten bin ich hier raus, ich habs nicht so mit landuse.

13

So abwegig scheint meine Vermutung ja nicht zu sein:

Verstehe ich das richtig? Um es mal ganz plakativ und überzogen auszudrücken: da werden nicht richtig getaggte Hecken schlecht gerendert (als Flächen, die keine Flächen sind) und anstatt das schlechte Tagging zu korrigieren wird das Rendering geändert um falsches/schlechtes Tagging richtig zu rendern. Dabei nimmt man in Kauf, dass nun bewusst und korrekt getaggtes Flächenmapping faktisch falsch gerendert wird und bisher offensichtlich falsch gemapptes nicht mehr einfach (optisch) als falsch erkannt und korrigiert werden kann.
Und weil nun flächig gemappt Hecken nicht mehr als Fläche gerendert werden ändert man die Bedeutung von scrub, damit dieses auch für flächiges Heckenmapping verwendet werden kann.

OSM ist schon eine verrückte Welt!

PS (plakativ und provokativ):
Das Ändern des Renderings ist ungefähr so begründet: weil viele user Gebäude mappen und dabei fälschlicherweise idiotischerweise landuse=grass verwenden, was gerendert offensichtlich falsch aussieht, rendert man lieber alle landuse=grass in zartem Gebäude-Rosarot.

14

Nun, die Zahlen sprechen dagegen, da muss man aber selber das ohsome dashboard aufrufen.

Nichts dagegen einzuwenden, die Micro-mapper aller Länder, wenn ihnen schon kein neuer Tag einfällt, der auch akzeptiert wird, (shrubbery ist meiner Englisch Kenntnisse nach weder natural noch landuse, sondern ein leisure:garden:type), sollen meinetwegen etablierte verwenden für ihre 10m² Flicken, aber bitte nicht einen etablierten tag so umdefinieren, dass diejenigen, die es bisher korrekt gemacht haben, dann etwas nachpflegen müssen, damit es weiterhin korrekt bleibt.

Bleibt zu beklagen, dass die vorgeschlagenen feature Details auf manierte Hecken gut zutreffen, an der Botanik aber ziemlich vorbeigehen.

15

ich bezog das dieses Mal nicht auf die Zahlen sondern auf eine der Intentionen des Proposal:

Und es wird bereits teilweise so gemacht:
https://www.openstreetmap.org/way/884716198#map=19/52.39408/4.83742
vs.
https://www.openstreetmap.org/way/884716255
Und das vom gleichen User im gleichen CS. Das sieht für mich schon nach einem Test aus, auf Bildern erkenne ich da keinen nennenswerten Unterschied.

16

Wieso redet ihr jetzt über barrier=hedge, das steht doch im Proposal inklusive Links wieso das nicht im Frage kommt weil es mit area=yes niemals als area interpretiert werden wird.

Es wäre nur fair, ein Proposal komplett zu lesen wenn man vor hat, dafür oder dagegen abzustimmen.

17

barrier=hedge und natural=scrub sind keine natürlichen Gegensätze. Das eine beschreibt die Funktion als Einfriedung oder Abgrenzung, das andere die Beschaffenheit. Ich finde es auch doof, Gebüschstreifen an einem Feldweg als barrier=hedge zu taggen, weil man damit halt ganz einfach eine grüne Linie in die Karte bekommt (zB hier https://www.openstreetmap.org/way/409059440 und Umgebung).

Wenn wir da einfach mal sagen, jede Sorte Gebüsch ist erstmal natural=scrub und das lässt sich dann noch verfeinern, wäre mehr KISS drin :slight_smile:

18

Das ist wohl klar. Scrub für Hecken ist eine, wenn nicht die Hauptanwendung. Der density Parameter zielt auch sehr auf die Barrierewirkung.

19

Mit dem Punkt komm ich hier scheints nicht durch: Wenn man die Kontinuität der Dokumentation betrachtet:

Bisher ist unkultiviert (maintained=no) der Defaultwert. Mit dem Akzeptieren des proposals wird es keinen Defaultwert für die Kultiviertheit mehr geben. Wo nach Dokumentation gemappt wurde, da geht Information verloren, wo nicht, da kommt nichts dazu.

20

Den Defaultwert eines nicht vorhandenen Tags legt ohnehin jeder Auswerter selber fest. Nur weil ein maintained=* hinzu kommt, ändert sich nichts an der Auswertung. Den Default wird evtl. ein Niederländischer Auswerter anders auslegen als ein Deutscher. Aber das ist nichts was wir Mapper beeinflussen können. :wink:

Aktuell ist es Kraut und Rüben ohne Möglichkeit, es genauer zu definieren.