Oh, sorry. War der Haken entfernt, kommt nicht wieder vor.

Gruß - Michael

@silversurfer83, alles gut!
@dieterdreist-CAI, stimme mit dir völlig überein.
Eine sehr "angenehme" Debatte, vielen Dank!

Hallo silversurfer83,

die L 578 ist gemäß der in Deutschland definierten Regelfahrbahnbreiten mindestens 7,5 Meter breit und durchschneidet die Waldfläche in diesem Verlauf auf einer Länge von über 300m und zwar im wahrsten Sinne des Wortes "pysikalisch". Das sind in diesem Fall zusammen mindestens 2250 m² Fläche, die vor meiner Aufteilung fälschlicherweise als landuse=forest angesprochen sind. Würde man Luftbilder aus einem Winterhalbjahr unterlegen, wäre die nicht von Bäumen bewachsene Trasse der L 578 deutlich sichtbar. OSM-highways sind Vektoren, können also keine Flächen belegen, OSM-landuse, -natural, etc ., dagegen schon und definieren diese Flächen mit konkreten Eigenschaften, wie z.B. "forest=Fläche mit Bäumen bewachsen".
Es ist offensichtlich selbstverständlich, dass u.a. OSM-Forest-Flächen entlang breiterer BAB-Trassen und anderen mehrspurigen Autostraßen immer aufgetrennt werden. Gibt es in Hinblick "Waldflächen-kreuzende" Autobahn und "Waldflächen-kreuzende" Landstraße einen Unterschied?
In meinem Verständnis kann die Frage, ob Waldflächen entlang "durchlaufender" Straßen aufzuteilen sind, eigentlich gar nicht gestellt werden.

Viele Grüße - Michael

Hallo PT-53,
das "Zeiler Saugatter", way/974350799, war in V1 als landuse=forest, inkl. der aktuellen Attribute "produce" erfasst. Die Fläche befindet sich zu geschätzt 70% innerhalb, zu geringen Teilen aber auch außerhalb der 2008 erfassten Relation 9991, landuse=forest, type=multipolygon.
Ich habe im Zuge der Aufspaltung BAB-überlappender forest-Flächen, die Zuweisung landuse=forest aus way/974350799 entfernt, stattdessen entsprechend der in V1 hinterlegten Beschreibung
"Saugatter bei Schloss Zeil als ausgewiesene Fläche hinzugefügt. Die Begrenzung ist gemäß Zaun und Wildroste. Einige Stellen waren nicht erreichbar mit GPS. Geschätzt gemäß optischen Verlauf.",
barrier=fence eingetragen.
"produce" erscheint mir auch völlig abwegig, zumal die Holzproduktion durch das darüber liegende Multipolygon landuse=forest eindeutig beschrieben ist.

Klar, das Koppeln von Flächen vereinfacht die Erfassung. Der Nachteil ist in meinen Augen, dass ein Stückchen Präzision verloren geht. Z.B. ist eine farmland-Parzelle in Deutschland immer durch einen Blühstreifen vom angrenzenden Feldweg getrennt. Werden landuse und highway zusammengelegt, wird der Blühstreifen zu landuse in OSM, also landwirtschaftliche Anbaufläche. Die Ackerfläche wird so um die halbe Fläche des angrenzenden Feldwegs vergrößert. Dazu kommt, dass benachbarte Feldflächen i.d.R. an mindestens 2 Seiten durch eine Wegeparzelle separiert sind, diese in OSM meist nicht erfasst ist.
Aber letztlich sind das Diskussionen, die schon ziemlich in das tiefste Detail gehen.

Guten Morgen,
habe mir auch deine Edits an der Stelle noch einmal angesehen und keine Kollisionen erkannt.
Die durch meine Trennung entstandenen 2 großen Forest-Einzelflächen, links und rechts der A29, müssten Multipolygone sein, weil sich innerhalb der beiden Flächen jeweils weitere landuse/natural befinden.
Ich vermeide das direkte Koppeln benachbarter Flächen. weil sich dadurch die spätere Pflege, z.B. wenn aus orchard farmland werden sollte, deutlich erschwert.

Hallo Discostu36,
es gab keine "mechanische" Korrektur. Ich habe in Summe 4-6 building=yes im Raum Rostock und Schleswig, die zusätzlich mit landuse=garages, bzw. greenhouse_horticulture getaggt waren, manuell geladen und von "building=yes" auf "building =garages", bzw. "building=greenhouse" geändert.
Zu dem Zeitpunkt befand sich leider noch einen Auszug aus OSM für ganz Norddeutschland mit diversen anderen Dingen im Speicher. Das hatte ich übersehen.

Hallo Niiepce,

vielen Dank für die Info! Da ist mir ja ein dicker Klopper passiert. Habe die Flächen eben korrigiert.

@silversurfer83,
keine Sorge. Mir liegt es völlig fern, irgendeinen "Editwar" anzuzetteln. Ich bin vor ca. 2 Jahren selbst von einem Mitglied aus der Community aufgefordert worden, statt "building", "man_made=slurry_tank" zu verwenden. Dabei wurde explizit zurecht auf den Widerspruch aus der "building"-Definition verwiesen.

@PT-53, "hinbiegen" ist genau der Terminus, der mich davon abhält, in dieser Community mitzumachen. Ich argumentiere rein sachlich in Hinblick auf die OSM-Systematik. Der nachgelagerte Verwendungszweck spielt überhaupt keine Rolle, im Gegenteil: Jede nachgelagerte Verwendung von OSM-Daten krankt an den gleichen Stellen.

Ja, das ist auch gut so. Ich bin davon überzeugt, dass ich gute Gründe habe, manches "anders zu sehen". Wenn man sich mit den Schlüssel-Definitionen in OSM auseinandersetzt, dazu begreift, dass die Schlüssel-Systematik eine hierachische Wirkung hat, spricht doch gerade in Hinblick "man_made=slurry_tank" einiges für meine Sichtweise.
Ich hätte auch nichts dagegen, wenn "man_made=storage_tank" so erweitert würde, dass "slurry_tank" unterscheidbar von anderen "storage_tank" getaggt werden kann. Aktuell jedenfalls ist der Stand in OSM Kraut und Rüben.
Es wäre jedenfalls schön, wenn sich das ein, oder andere mal in Bewegung setzen ließe, statt zuzulassen, dass sich das vorhandene Sammelsurium auf ewig konserviert.

Viele Grüße!

Das sehe ich etwas anders: "storage_tank" ist laut OSM-Wiki als geschlossener Tank definiert, z.B. auch unter Druck stehend. In jedem Fall aber mit festem Dach.
Ein "slurry_tank" ist oftmals oben offen, dazu ist die Sohle aufgrund des großen Durchmessers meist etwas im Erdreich eingelassen. Genau aus diesem Grund gibt es den separaten Key "slurry_tank".
"content=manure/slurry" in Verbindung mit "storage_tank", steht für mich für Faulgas-/Gärbehälter z.B. innerhalb einer Kläranlage.

Sorry, wenn ich gleich am Montag so tief in der Sch... wühlen muss.

Viele Grüße!

Guten Morgen,
es gibt darüber Diskussionen:
Laut OSM-Wiki muss "building=slurry_tank" getaggt werden. OSM-Wiki sagt aber auch, dass zwischen "building" und "man_made" so unterschieden werdern soll: "building" steht für etwas betretbares, "man_made" dagegen für vom Menschen errichtete Anlagen, die für sich gesehen nicht betret-, bewohnbar sind.
Die Zuordnung "slurry_tank" in die Gruppe "building" für Güllebehälter ist sicherlich unpassend und widerspricht der eigenen Logik.
Ich gehe davon aus, dass in nicht allzu ferner Zukunft "man_made=slurry_tank" in OSM-Wiki auftauchen wird.

Viele Grüße!

Sorry, da lag ich daneben. Es scheint sich eher um Pferdeställe zu handeln. buildings auf yes zurückgesetzt.

Hallo chris66,

da hast du Recht, sorry! Habe das korrigiert.

Einfach nur lächerlich! Meine Änderungen waren allesamt geprüft, händisch differenziert ausgeführt und sachlich gem. den mir zur Verfügung stehenden Informationen richtig.
Dein Revert stellt den wesentlich schlechteren Zustand wieder her. Das ist auch eine Art, OSM voranzubringen.
Im Übrigen wäre es hilfreich gewesen, du hättest bereits bei der Erfassung dieser Entries in OSM dafür Sorge getragen, dass alles OSM-konform erfolgt. Es gäbe dann nämlich keinen Bedarf, derartige Änderungen durchführen zu müssen. Statt dessen sinnierst du über eine "dauerhafte Sperre". In Hinblick auf dein undifferenziertes Revert meiner Änderungen - wir reden über "slurry_tanks", "storage_tanks" und "digester" (!) - würde ich im ersten Moment auch nachdenken, wäre es nicht so armselig.

Das solltest du dir mal genau überlegen: "train_station" impliziert eine eindeutige und fortdauernde(!) Nutzung dieses Gebäudes. Das kann aber dann nicht stimmen, wenn aktuell eine Religionsgemeinschaft das Gebäude nutzt. Das Bahnhofsgebäude in meinem Heimatort ist schon vor 40 Jahren in ein Mehrfamilien-Wohnhaus umgebaut worden, die Hülle ist aber geblieben.
Der OSM-Key "building" beschreibt die grundsätzlichen, also gegebenen Architektur-Eigenschaften eines buildings.

Das hat damit überhaupt nichts zu tun! Du sprichst von der Nutzung eines Gebäudes und die wird in OSM über den Tag amenity, religion, ggf. demonination beschrieben.

Haarspalterei: Die OSM-Datenbank liefert mir für die betroffene Postion: "landuse=residential" und "building=yes". Bleibt nicht mehr viel Platz für Interpretationen.

Aber in Hinblick auf eine isolierte Nutzung von Maps4BW als Quelle, sind wir ja einer Meinung.

Ich verdrehe weder Aussagen, bezweifele keine Ortskenntnisse, oder vorlaufende Erkundigungen, noch nehme ich für mich in Anspruch, der "Wahrheit" entsprechend in OSM zu arbeiten: Wir müssen uns nur bewusst machen, dass es keine alleinige Quelle der wahren Erkenntnis gibt. Der alleinige Bezug auf Kataster-Karten, oder noch schlimmer Kataster-Imports wie "Kapor" in der Slowakei, kann OSM nur mit Umrissen versorgen, die für sich allein betrachtet "nur" eine Kopie der Kataster-Karte in OSM abliefern. Formal entsprechen die Edits zwar den OSM-Regeln, aber wozu soll ich eine frei verfügbare Kataster-Karte in ein System kopieren, das von Eigenschaften lebt, die die Welt beschreiben?
Maps4BW, genau wie die anderen Kataster-Quellen, sind nur zusammen mit den Bildquellen brauchbar. Letzlich können es aber nur die Bildquellen sein, die im Zweifel die Richtung angeben.
Ich stelle überhaupt nicht in Abrede, dass die Eigenschaft "building=commercial" korrekt recherchiert ist. Es wäre dann aber hilfreich gewesen, wenn die Fläche "landuse=farmyard" entsprechend angepasst wäre. Ich wäre so nie auf die Idee gekommen, dem building eine andere Eigenschaft zu geben. Noch besser wäre es gewesen, wenn die Abwicklung des Gebäudekomplexes gleich aufgeteilt worden wäre.
In Reutlingendorf gibt es ohnehin noch genug Arbeit: Innerhalb der "landuse=residential"-Fläche, gibt es z.B. Bauernhöfe, deren Gebäude nur als "building=yes" getagt sind. OSM interpretiert diese Buildings dann eben auch als "residential".

Jetzt zu diesem Gebäude:
Es handelt sich um ein Haupthaus mit einem Anbau. Deutlich zu erkennen an Dachhöhen, Firstverläufe. Siehe dazu WIKI DE:Gebäude Absatz Umriss, 1.Satz. Dazu kommt, dass das Haupthaus offensichtlich in südöstlicher Richtung erweitert wurde (am Dach erkennbar). Außerdem gibt es, an der Längsseite Innenhof angelehnt, einen weiteren schmalen Anbau.
Überhaupt: Der in Maps4BW hinterlegte Grundriss scheint eher "mäßiger" Qualität zu sein. Betrachtet man die Lage des First, deutlich in Bing zu erkennen, ist das Dach symmetrisch. Daraus folgt, dass der Ringanker des Gebäudes mindestens in großen Teilen ebenfalls symmetrisch, analog zum Dach, verlaufen muss. Maps4BW suggeriert aber, sofern als Grundriss das Mauerwerk bezeichnet ist, eine asymmetrische Anordnung. Das ist in meinen Augen extrem unwahrscheinlich.

Du hast die Fläche des betroffenen Areals als "landuse=farmyard" getagt. Da ist ein "building=commercial" völlig unpassend. Sollte tatsächlich in dem Gebäude eine "commercial"-Nutzung vorhanden sein, wäre diese über einen Node, z.B. "shop=" zu erfassen, oder aber "landuse" stimmt nicht.

Zu deinem Hinweis "i.d.R. vorher vor Ort erkundet": Das ist zwar sehr lobenswert, in Hinblick auf die in OSM zu hinterlegende Datenmenge aber nur ein frommer Wunsch.

OSM ist keine Katasterkarte, oder Messtischblatt, sondern modelliert die gesamte Welt. Die Erfassung der Daten kann nur über Luftbilder und anderer Hilsmittel in einem großen Abbildungsmaßstab erfolgen. Die Präzision der per Hand erfassten Daten muss daher wesentlich unschärfer sein, als das, was ich täglich per Laser in 1/10 mm vermesse. Das ist aber auch nicht der Anspuch von OSM. Die Modellierung der Welt in OSM bedeutet, dass Eigenschaften die wesentliche Rolle spielen. Typische kartographischen Angaben sind nur ein kleiner Teil vom Ganzen. Dazu kommt, dass OSM digital gefüttert werden muss. OSM kennt z.B. nur Ecken, keine analogen Kreise.

Na ja und dann bleibt immer noch das Thema, dass wir OSM-Mapper ein reales 3D-Objekt in 2D erfassen.