Was ist das Richtige Tag für Güllebehälter ?

Nach schnellem Drüberlesen hat man_made=storage_tank zahlenmäßig die Nase vorn (90.000 Punkte + 400.000 Linien laut taginfo) und building ist eher nicht angebracht. Wieviele dieser Objekte aber zusätzlich ein building=* haben, müßte man noch overpass fragen.
Ich komme aber erst am Abend dazu das genauer anzuschauen.

Die ersten waren meist aus Beton - also rechtfertigen mE. building.
Die neueren aus Stahl wäre für mich auch kein building.

FreiTal wrote:

Die ersten waren meist aus Beton - also rechtfertigen mE. building.
Die neueren aus Stahl wäre für mich auch kein building.

Ob Beton oder Stahl: Eine geschlossene Güllegrube hat keine Türe um diese jederzeit betreten zu können = kein "Gebäude"

Verstehe ich das richtig? Eine Konstruktion ohne "Türe um diese jederzeit betreten zu können" ist nie ein building=* ?

GerdP wrote:

Verstehe ich das richtig? Eine Konstruktion ohne "Türe um diese jederzeit betreten zu können" ist nie ein building=* ?

Zitat aus DE:Key:building
- https://wiki.openstreetmap.org/wiki/DE:Key:building

Der Schlüssel building wird zur Kartierung von Gebäuden benutzt, siehe Gebäude auf Wikipedia. <<<

Zitat aus Wikipedia:
- https://de.wikipedia.org/wiki/Geb%C3%A4ude

Ein Gebäude ist ein Bauwerk, das Räume einschließt, betreten werden kann .... Ein Gebäude besitzt nicht zwingend Wände oder einen Keller, jedoch immer ein Dach. <<<

Lassen wir mal die Türe weg. Eine Güllegrube kannst Du nicht jederzeit betreten und ein Dach haben viele auch nicht.

Ich muss noch mal genau drauf achten, aber ich frage mich, ob alle Objekte, die ich mit building=digester erfasst habe, tatsächlich eine - wie auch immer geartete - Tür haben...

GerdP wrote:

Ich muss noch mal genau drauf achten, aber ich frage mich, ob alle Objekte, die ich mit building=digester erfasst habe, tatsächlich eine - wie auch immer geartete - Tür haben...

Ich halte building=digester genauso für falsch wie buidling=storage_tank.

Bzgl.

PT-53 wrote:

GerdP wrote:

Ich muss noch mal genau drauf achten, aber ich frage mich, ob alle Objekte, die ich mit building=digester erfasst habe, tatsächlich eine - wie auch immer geartete - Tür haben...

Ich halte building=digester genauso für falsch wie buidling=storage_tank.

Bezüglich Gebäude und Türen... In wikipedia zur Güllegrube steht etwas von "Bauwerk" und laut Wörterbuch ist Bauwerk=building

GerdP wrote:

Verstehe ich das richtig? Eine Konstruktion ohne "Türe um diese jederzeit betreten zu können" ist nie ein building=* ?

einer Türe bedarf es m.E. nicht, aber betretbar oder evtl. auch nur bekriechbar sollte es schon sein.
Beton alleine reicht mir nicht, da ist Stahl genauso gut, aus Beton kann man sogar Kanus bauen, und die wiederum würde man kaum als Bauwerke bezeichnen, oder? (Flugzeugträger schon eher)

AB-inf-x-chg-AB wrote:

Bezüglich Gebäude und Türen... In wikipedia zur Güllegrube steht etwas von "Bauwerk" und laut Wörterbuch ist Bauwerk=building

ich könnte mir vorstellen, dass es beides gibt, Güllegruben die für uns ein building sind, und andere.
Bauwerk ist im deutschen Baurecht nicht definiert (AFAIK), es gibt zwar bauliche Anlage als Begriff, aber davon ist sicherlich nicht alles “building”.

dieterdreist wrote:

es gibt zwar bauliche Anlage als Begriff, aber davon ist sicherlich nicht alles “building”.

Nein, dehalb gibt es ja auch in OSM man_made=*
🙂

Bauliche Anlage sind das ja auch alle.

Ja klar gibt es dafür auch man_made=* das wird aber auch sehr oft mit building=yes zusammen erstellt.
Habe zu dem Thema grade noch einge ältere Forums beitrege gelesen bei dem Biogasanlagen:
building=digester wird das wohl schon so richtig sein. Das ganze wurde wohl 2019 eingefürt damit man die vernünftig erfassen kann.
Die haben übrigens auch 1 Tür welche aber nur zu Wartungszwecken bei Auserbetriebnahme der Anlage genutzt werden kann.

Bei den Gülletanks würd ich nicht zwischen Beton und Stahl unterscheiden da die sich nur im Material der Wände unterscheiden. Fundermente sind bei beiden aus Beton.
Gibt daneben noch den Anlagentypen Güllelagunen welcher sich Baulich unterscheidet da das nur Folie in einer Erdgrube ist.
Als beispiel was das ist: https://www.guellelagune.de/

Ich habe mir gerade ein paar building=digester angeschaut. Eine Tür habe ich nicht gefunden, aber so eine Art Wartungsschacht, durch die man vermutlich reinkriechen könnte. Wird ja nur selten nötig sein, und ich könnte mir auch vorstellen, dass man dann die Plane oben entfernt und über den Rand "krabbelt".

Eine ausführliche Diskussion über diese Objekte wurde bereits 2010 gestartet und vor nicht allzu langer Zeit noch einmal weitergesponnen ... hat auch damals schon zu keinem eindeutigen Ergebnis geführt ... 🙄

Siehe hier: https://forum.openstreetmap.org/viewtopic.php?id=7086

Link angehängt

Danke Map Hero für den Link. Bin leider nicht auf die idee gekommen das vorher zu suchen.
Gabe dort ja einige gute ansätze irgentwie schade das in 12 Jahren daraus keine einheitliche überarbeitung für die wiki´s entstanden ist.

Nach dem was mann iin der ausführliche Diskussion so lesen kann ist wohl building=slurry_tank weiter verbreitet.

Habe das mit Overpass grade mal für Schleswig - Holstein geprüft
Für man_made=storage_tank + building=yes gibt es Nodes: 29401, Ways: 1591
Für building=slurry_tank gibt es Nodes: 66860, Ways: 3796,

Unabhänig von der hier geführten debatte was nun ein Gebäude tag haben sollte und was nicht. (Denke das sollte man wen mal auf oberster ebene klären)
Ist ein Gebäude Tag bei den Gülletanks laut dem was ich sehen kann wohl der normalzustand.

Beide Varianten sagen ja im prinzip auch das gleiche aus.

Da aber building=slurry_tank doppelt so oft genutzt wird und auch in meiner umgebung alles auser die von mir bearbeitete so gemappt sind werde ich das zukünftig auch nutzen.

Hmm, die Zahlen können nicht stimmen. Laut taginfo gibt es weltweit nur 35000 Objekte mit building=slurry_tank:
https://taginfo.openstreetmap.org/tags/ … lurry_tank

Kann sein das ich was falsch eingegeben habe, kenn mich mit overpass noch nicht so gut aus.:rolleyes:

Ich hatte die nodes und ways die angezeigt wurden in mein beitrag reinkopiert und dachte die ways stehen für die anzahl der Objekte und die Nodes für die punkte bei den objekten somit wären das dann 3796 von den 35000 die in schleswig holstein gemappt sind.

Map_HeRo wrote:

Eine ausführliche Diskussion über diese Objekte wurde bereits 2010 gestartet und vor nicht allzu langer Zeit noch einmal weitergesponnen ... hat auch damals schon zu keinem eindeutigen Ergebnis geführt ... 🙄

Siehe hier: https://forum.openstreetmap.org/viewtopic.php?id=7086

Link angehängt

Danke fürs Raussuchen. Da ist ja alles schon mal ausführlich diskutiert.
Also im Prinzip eher kein building, sondern man_made. Das zusätzliche building=yes stammt a) von iD, b) vom Wunsch nach Rendern als Fläche. Da die Dinger aber eh schon meist als geschlossene Linie, d.h. Fläche eingezeichnet sind, müßte OSM-Carto überzeugt werden.

Wir wären also bei

Map_HeRo wrote:

... in #35 der oben verlinkten Diskussion
Mistlagerplatz: man_made=bunker_silo + content=manure
Güllebeghälter: man_made=storage_tank + content=slurry

Rainero wrote:

Also im Prinzip eher kein building, sondern man_made. Das zusätzliche building=yes stammt a) von iD, b) vom Wunsch nach Rendern als Fläche.

Das denke ich auch und das gilt m.E. nicht nur für das zusätzliche building=yes, sondern auch für den tag building=slurry_tank.

Rainero wrote:

Da die Dinger aber eh schon meist als geschlossene Linie, d.h. Fläche eingezeichnet sind, müßte OSM-Carto überzeugt werden.

+1

... und dann müsste mal jemand mit Erfahrung die entsprechenden Wikiseiten aufräumen ... 🙄

Rainero wrote:

Danke fürs Raussuchen. Da ist ja alles schon mal ausführlich diskutiert.
Also im Prinzip eher kein building, sondern man_made. Das zusätzliche building=yes stammt a) von iD, b) vom Wunsch nach Rendern als Fläche. Da die Dinger aber eh schon meist als geschlossene Linie, d.h. Fläche eingezeichnet sind, müßte OSM-Carto überzeugt werden.

Ist alles nicht so einfach wie ich gedacht habe.
Das problem ist demnach ja einfach nur das flächenobjekte mit man_made=* nicht gerendert werden.

Deswegen sind wohl schon vor vielen Jahren die building=yes ergänzung und building=slurry_tank entstanden.

Ich denke auch die beste Lösung wäre wen OSM-Carto diese objekte auch als Flächen anzeigen würde.
Die sind ja zum teil auch recht große flächen. Als Beispiel ein Fahrsilo: https://www.openstreetmap.org/way/10200 … 605/9.5768

Aber so lange es dazu keine einheitliche lösung gibt sind erstmal alle verbreiteten Varianten OK.
Deswegen werde ich es auch lasse und erstmal keine schon eingetragenen Güllebehälter überarbeiten.

puma515 wrote:

Ich denke auch die beste Lösung wäre wen OSM-Carto diese objekte auch als Flächen anzeigen würde.
Die sind ja zum teil auch recht große flächen. Als Beispiel ein Fahrsilo: https://www.openstreetmap.org/way/10200 … 605/9.5768

Es gibt ja auch noch ganz andere riesige Anlagen mit storage tanks, z.B. für alle Arten von chemischen Produkten, Öl, Kraftstoffen etc. Da stehen teilweise Dutzende von Tanks mit einem Durchmesser von zig Metern, von der Sache her ganz klar technische Behälter, also "man_made=" und keine "buildings".

Von daher ist mir absolut unverständlich, warum die (wenn sie als area erfasst sind und nicht nur als node) in carto nicht als Flächen gerendert werden, sofern man für diesen Zweck nicht noch ein building=yes dranhängt, wie im deutschen Wikibeitrag (aber auch nur dort!) vorgeschlagen. Als hätte man noch nie was von "wir taggen nicht für den renderer" gehört.

puma515 wrote:

Deswegen werde ich es auch lasse und erstmal keine schon eingetragenen Güllebehälter überarbeiten.

Würde ich auch nicht machen, solange genau dieser Punkt nicht geklärt und im Wiki dokumentiert ist.

Ich finde https://www.openstreetmap.org/#map sollte hier genauer rendern - eben nach WIKI.
Bei jeder andere Anwendung kann dann auf die "Originalkarte" verwiesen werden.
Leider ist auch "Mist", das jeder undiskutiert das WIKI ändern kann - ja sogar seine eigenen Tags eintragen kann.

FreiTal wrote:

Leider ist auch "Mist", das jeder undiskutiert das WIKI ändern kann - ja sogar seine eigenen Tags eintragen kann.

Ne, das ist ja gerade das Ziel von OSM.....

Was wichtiger wäre, wäre eigentlich eine überwachte Tagging-Datenbank, wo wir mal alle "approved"-Tags mit Abhängigkeiten und ggf. sogar Defaults darstellen können.
Dies würde sowohl Mappern (in Form von Presets in den Editoren) als auch Datenusern (Renderern und ggf. auch anderen Darstellunge, vielleicht sogar vernünftige Übersetzungen) einen großen Vorteil bieten....

in letzter Zeit kommt das selten vor, insbesondere im internationalen Wiki, aber so ganz unrecht hat Freital nicht, wenn undiskutiert die Definitionen von genutzten tags geändert werden führt das durchaus zu Problemen und wenn es nicht schnell genug entdeckt wird kann es im Extremfall auch dazu führen dass ein tag komplett unbrauchbar wird.

Eigene tags (neu) zu dokumentieren, vor allem wenn deren Schlüssel nicht mit denen von Alternativtags kollidieren, ist dagegen erwünscht, im Zweifel ist es da aber auch besser, die Sache vorher zu diskutieren.

Moin,

+1 @dieterdreist - aber ...

Map_HeRo wrote:

puma515 wrote:

Deswegen werde ich es auch lasse und erstmal keine schon eingetragenen Güllebehälter überarbeiten.

Würde ich auch nicht machen, solange genau dieser Punkt nicht geklärt und im Wiki dokumentiert ist.

hhmm - sehe ich etwas anders: Ein (quasi) Henne-Ei-Problem kann man am ehesten lösen, indem man das Objekt als Henne und als Ei taggt. 😉

Wenn es zwei relativ gleich große unterschiedliche (aber sich nicht gegenseitig ausschließende) Taggingvarianten gibt, würde ich immer die sinnvoll gewünschte Variante zusätzlich, also ggf. beide taggen.
Nur so hat ein Auswerter die gleiche Wahlmöglichkeit - und nur so kann man ihn vielleicht überzeugen, umzuschwenken ...

Sonst bleibt es auf ewig das gleiche Herumgeeiere, denn die bereits ausgewertete Variante wird immer die Überhand behalten - dann kann man sich gleich darauf einigen.
Dieses theoretische Wiki-Drehen eines praktischen Daten-Bestandes hat bislang bei OSM trotz vorheriger Diskussion selten geklappt ...

Grüße
Georg

SafetyIng wrote:

Was wichtiger wäre, wäre eigentlich eine überwachte Tagging-Datenbank, wo wir mal alle "approved"-Tags mit Abhängigkeiten und ggf. sogar Defaults darstellen können.
Dies würde sowohl Mappern (in Form von Presets in den Editoren) als auch Datenusern (Renderern und ggf. auch anderen Darstellunge, vielleicht sogar vernünftige Übersetzungen) einen großen Vorteil bieten....

+1 ... full acc ... 100% Zustimmung ... 😄

dieterdreist wrote:

Eigene tags (neu) zu dokumentieren, vor allem wenn deren Schlüssel nicht mit denen von Alternativtags kollidieren, ist dagegen erwünscht, im Zweifel ist es da aber auch besser, die Sache vorher zu diskutieren.

Ich würde mal sagen, es ist nicht nur im Zweifel besser, neue Tags vorher zu diskutieren (also bevor man sie ins Wiki schreibt), sondern grundsätzlich besser.