Gasanlage komplett zurückgebaut, wie taggen?

-1

Landuse=bownfield sollte bitteschön nur angwendet wertden, wenn ein ehemals bebautes Areal wieder bebaut werden soll, so verstehe ich landuse=brownfield.

-1
Zum was=* warum was neues erfinden, für etwas, was es bereits gibt… Stichwort https://wiki.openstreetmap.org/wiki/DE:Lifecycle_prefix

Sven

Ich habe - glaube ich - noch nie ein Gelände als landuse=brownfield erfasst. Nach meinem Verständnis passt der Begriff nur in der typischerweise sehr kurzen Zeit zwischen Abriss eines oder mehrerer Gebäude und dem Moment, an dem man wieder landuse=construction setzten kann/muss. Wenn ich aber Sperrungen an Strassen, die “nur” zwei-drei Wochen dauern, nicht mappen soll, dann interessieren mich die paar Tage, an denen so ein Gelände noch keine Baustelle ist, praktisch gar nicht. Hängt aber wahrscheinlich von der Gegend ab, anderswo werden ja Gebäude abgerissen, weil sie nicht mehr gebraucht werden und nicht, weil man dort sofort - und meist deutlich größer - neu bauen will.

Bro, das hat sich doch schon längst überholt, siehe #18 … es sollte heißen was:landuse=* und das ist bereits im wiki dokumentiert.

Die Definition im wiki ist wesentlich weiter gefasst, da heisst es u.a.:

Da steht also keinesfalls als Bedingung " … and will be subject to construction activities in due time".

Ich verstehe brownfield so, dass darunter jedes Gelände fällt, wo eine von Menschen gemachte Struktur beseitigt oder planiert wurde, teilweise sich auch im Zustand des Verfalls befindet, aktuell nicht genutzt wird, und noch nicht klar ist, was da mal draus werden soll. Dieser Zustand kann durchaus jahrzehntelang andauern, wie man an diversen Industriebrachen erkennen kann. Er kann aber auch nach wenigen Wochen vorbei sein, wenn eine neue Nutzng zu erkennen ist.

Die Definition trifft auf die beseitigte Gasanlage m.E. absolut zu, auf die unter #20 zitierten Sandgruben oder auch Steinbrüche nicht - aus einer Sand/Kiesgrube wird nach Aufgabe normalerweise ein See bzw. Teich und ein Steinbruch bleibt im Normalfall für Jahrzehnte ein (aufgegebener) Steinbruch. Er existiert also weiterhin, so dass dann wohl eher ein lifecycle prefix die richtige Wahl ist.

Wie so häufig in OSM beinhalten aber auch diesen Begriffe eine gewisse Unschärfe und daher wird es vermutlich diesbezüglich auch keinen absoluten Konsens geben.

Tja, sieht ganz so aus als ob das engl. Wiki vor ein paar Wochen so geändert wurde, daß mein Verständnis eher nicht mehr passt. Bis Mitte Mai stand da was von “scheduled for new development”

Ich bin explizit gegen was=* und auch gegen was*=*

Warum was neues, wenn es die lifecycle-Prefixes gibt, die meiner Ansicht nach für diese Fragestellung zu 100% genauso angewendet werden können…

Sven

Ich setzte was:* wenn ich der Meinung bin, das dort nie das war, was da gemappt wurde Beispiel: Ein LKW wurde als building=yes erkannt. Dann nehme ich den was: prefix. Zumindest dann, wenn ich auf irgendwelchen Luftbildern noch den Grund für den Fehler finde.
Sonst wird einfach gelöscht.

ich hab in meiner Gegend mal nach "was*=* "gesucht und bin bei keinem Fund auf einem Grund der Berechtigung dafür gestoßen. Meiner Meinung nach lässt sich alles stets mit Lifecycle-Prefixes oder ähnlich abbilden…

Beispiele:

  1. https://www.openstreetmap.org/way/613148665 was:name ist hier Quatsch wozu gibt es old_name?
  2. https://www.openstreetmap.org/way/23443765was:landuse=quarry ist hier Quatsch: Bei dem Beispiel allerhöchstens disused:*, denn das Areal unterliegt mit Sicherheit noch dem Bergrecht und obwohl es NSG ist könnte ein neuer Eigentümer wieder mit der Kiesgewinnung anfangen.
  3. https://www.openstreetmap.org/node/1852934146 Wenn Betreiber und Webseite sich geändert haben, bedarf es nicht zusätzlich was:webseite; im Übrigen sind beide hinterlegten Adressen (webseite=* und was:webseite=* weiterhin aktiv.
  4. https://www.openstreetmap.org/way/477469760 warum nicht old:addr:street?
  5. https://www.openstreetmap.org/way/358625158 war mal als historic:landuse=militaty von mir erfasst. Erst mit CS https://www.openstreetmap.org/changeset/118284530 wurde es vermalledeit. Ich halte hier historic noch immer für besser. Alternativ wären andererseits die Lifecycle-Prefixes durchaus detailierter…

So kann ich alle Funde hier durchgehen… Ich sehe bisher keinen Grund für die Existenz von was*=*

Sven

Ja, das ist neben den Unschärfen bei der Abgrenzung von Attributen ein weiteres OSM Problem … man kann sich nicht sicher sein, dass das, was man gestern im wiki gelesen hat, morgen noch genau so wiederzufinden ist … :sunglasses:

Unabhängig davon macht das “brownfield” für mich in der von mir zitierten Bedeutung aber auch mehr Sinn als mit der Einschränkung “scheduled for development”, schon alleine weil man dem Gelände, das aktuell ganz oder teilweise geräumt, planiert oder dem Verfall preisgegeben ist, oftmals überhaupt nicht ansehen kann, was als nächstes damit geschehen soll, den aktuellen Zustand aber schon. Und da wir primär den aktuellen Zustand mappen, sollten auch die verwendeten Tags sich primär darauf beziehen und nicht auf etwas, was eventuell in der Zukunft mit einem Objekt passieren wird.

…und das halte ich für ein essentielles Problem! :expressionless:
Es sollte ein Weg gefunden werden, wie man da gegensteuern kann… Wiki-Arbeitsgruppe oder so? Meiner Meinung nach sollte nicht einfach jeder in echten Tag-Definitionsseiten des Wiki herumeditieren können. Das Wiki muß dahingehend verläßlich sein.

Sven

Wieso was Neues …?!?.. was: ist genau so ein lifecycle prefix wir disused, abandoned oder razed und ist auch mit einer eigenen Bedeutung im wiki dokumentiert:

Es wird also bei Objekten gesetzt, die einem neuen Zweck erhalten haben oder sollen und ist mit rund 50K eines der am häufigsten verwendeten lifecycle prefixes. Ein Duplikat davon existiert mit dem tag “former”.

Das heisst natürlich nicht, dass die 50K “was” alle sinnvoll gesetzt sind, wie man an Deinen Beispielen erkennen kann … :smiley: … das gilt aber leider für viele andere tags genauso.

Hmnja…Bei dem, was ich gesehen habe, halte ich "was*=* zu 100% für obsolet und kann immer durch die genauer beschreibenden Lifecycle-Prefixes und ähnliches ersetzt werden.

Sven