Hallo,
möchte in meiner näheren Umgebung die Landnutzungsflächen auf Basis der neuen Bing-Bilder ergänzen bzw. korrigieren. Es gibt hier diverse ältere Flächenobjekte, die laut source-Tag von Landsat übernommen worden und ein Wirrwarr von Linienüberlappungen und z.T. gemeinsam genutzten Nodes bilden. Da mir nicht ganz klar ist, wie ich am besten vorgehen soll:
a) Jede Fläche als eigenständigen Way zeichnen bzw. aufsplitten und danach mühselig per Hand aneinander ausrichten oder
b) mit dem contourmerge-plugin im josm (scheint mir schneller und eleganter zu gehen)
Möchte daher noch einmal die Frage nach der “best practice” für das Mappen von Landnutzungsflächen aufwerfen.
Ich kann mich erinnern, dass das contourmerge-plugin hier schon einmal kontrovers diskutiert wurde, habe damals leider den Pfaden nicht zu Ende verfolgt bzw. finde den thread nicht mehr.
Gruß Gert
PS: Weis jemand, wie lange es dauert, bis bereinigte Fehler in keep rigth nicht mehr angezeigt werden?
Oh, je. Heikles Thema. Persönlich klebe ich landuse an landuse, wenn ich denke, dass in absehbarer Zeit nicht irgendwann mal jemand Daten/Luftbilder hat, um bspw die x-cm Grass zwischen den beiden Flächen zu mappen und ich es für vertretbar halte…kommt auch auf die Gegend an. Aber ich klebe nie landuse an Linien wie Straßen. Darüber ärgere ich mich oft…sehr sogar.
Meine Meinung (es gibt auch andere):
Wenn Flächen direkt aneinander grenzen (z.B. Wald/Wiese), gemeinsame Ways.
Wenn etwas dazwischen ist (Weg, Wassergraben etc.), getrennte Grenzen (die müssen nicht parallel sein).
Bitte nicht an “artfremde” Ways wie admin-Grenzen kleben.
Hauptstreitpunkt ist, ob man landuse-Grenzen an highway-Linien kleben soll. Zu Landsat-Zeiten mag das seine Berechtigung gehabt haben, bei heutigen Luftbild-Auflösungen ist das mMn überholt.
Überraschung: Bei einer umstrittenen Frage sind die ersten drei Antwortenden der selben Meinung (davon ausgehend, dass seichter mit “gemeinsame Ways” Ways mit gemeinsamen Knoten und keine MPs meint)
Nervend ist auch, dass einerseits tracks (Feldwege) in farmland-Flächen ausgespart werden und andererseits Flächen über riverbanks und mehrspurige Straßen drübergebügelt werden.
AFAIK bedeutet landuse überwiegende Landnutzung. Da sollten dann Feldwege, Feldraine (angesprochene x-cm Gras) dazugehören, wobei das Mappen letzterer IMHO total überzogen ist.
Konsisterentes Mappen/Taggen ist unumgänglich und erfordert zwangsläufig klare Regeln.
Wenn man das einigermaßen konsequent umsetzt, komme ich jedenfalls zu dem Schluß, daß man bei der heitigen Luftbildqualität in unseren Breiten Flächen hinreichend Flächenscharf abgrenzen kann (und sollte).
Feldwege: Bei Feldwegen, kann man auch die Landuses trennen, vor allem wenn neben dem Weg noch ein 2 Meter breiter Grasstreifen mit einzelnen Bäumen, einer Hecke oder ein Lesesteinhaufen ist.
Waldwege: Bei Waldwegen sehe ich es eigentlich ähnlich. Habe ich da einen Kronenschluß (Baumkronen berühren sich weitestgehend) halte ich eine Trennung für nicht nötig. Ist ein Kronenschluß nicht vorhanden können die Waldflächen an diesen Stellen getrennt werden. Durch den Wald laufende Stromleitungen, deren Schneisen im Luftbild eindeutig erkennbar sind, sind ein Trennungsgrund, der Bereich dazwischen als scrub, heath, sand, gras je nach Verhältnisse…
Straßen: Straßen sind eigentlich immer ein Trennungsgrund: zu mindestens ab tertiary und residental (innerorts *) )… Bei letzterem sehen das andere Leute anders… aber ich kann damit leben
*) Für mich ist das deshalb so, da man sonst Abgrenzungsprobleme bekommt, wenn z.B. auf der einen Straßenseite noch Wohnbebauung ist, auf der anderen Wiese oder ein Industriegebiet…
Gerade die heutige Luftbildqualität und die Zoomstufen machen eine feinere Kartierung möglich.
Ich war auch eine ganze Weile dieser Ansicht (habe in der Zeit aber praktisch kein Landuse kartiert, weil es eben so umstritten ist und mir ohnehin das Straßennetz wichtiger war). Daraus ergibt sich: Gleiche Landnutzung beiderseits der Straße / des Wegs: kein Auftrennen, und als logische Konsequenz bei unterschiedlicher Nutzung dann entsprechend die Straßen-/Wegmitte als Grenze.
Ich glaube aber inzwischen nicht mehr, dass sich die Sache mit der überwiegenden Landnutzung durchsetzen wird. Der Trend geht ziemlich deutlich immer mehr zum Micromapping, und das Problem ist, dass wohl niemand eine Grenze definieren kann, was noch überwiegende Landnutzung ist und was nicht.
landuse/natural an landuse/natural (waterway=riverbank)
river über riverbank, ähnlich ways über landuse
leisure/buildings z.B über landuse=residential
Das war am Anfang: Riesige MP (egal ob Wiese, Busch, Acker, Bauernhof) schnell als farmland/forest eingetragen.
Heute tragen wir Daten für Dachfarbe, Gebäudehöhe, Rolltreppe, … ein
ich trage das gern ein, bastl Kirchen zusammen und so, schau mal in Freiberg das war ich
ist aber bis jetzt nur geschätzt.
wir brauchen dringend 2,5d Daten
Ich möchte die Lage auch gerne noch mal zusammenfassen!
Es ist mathematisch unmöglich, Landnutzung exakt zu erfassen. Man muss sich für eine Genauigkeit entscheiden, und diese redaktionelle Arbeit ist etwas, was die vielen Menschen bei Openstreetmap besonders gut können. Es ist auf eine Art überhaupt nicht falsch, Nordafrika großflächig als Wüste, Sibirien als Wald oder den Spreewald als Sumpf zu erfassen Um so besser jedoch, wenn jemand die Genauigkeit erhöht, selbst wenn es zur Kartierung von Feldrainen kommt (was im übrigen dann nützlich ist, wenn das Feld bewachsen ist und man zwischen Wald und Feld entlangspazieren möchte).
Was aber Konsens sein sollte, das ist, unterschiedliche Informationsarten nicht zusammenzulegen, d. h. alles, das Wegenetz ist, also auch Waterways, komplett von allem, was Fläche beschreibt, zu trennen. Auch wenn Wege Begrenzungen bilden.
Vielen Dank für die aufschlussreiche Diskussion. Habe für mich jetzt einmal folgenden Workflow getestet:
In JOSM über die Filterfunktion alles außer “landuse=*” deaktivieren
mit dem contourmerge-plugin die Landnutzungsflächen aneinander ausgerichtet
“landuse=*” deaktivieren und den Rest, wie Straßen, Wege etc. wieder zuschalten und bearbeiten
Sieht für mich erst einmal ganz brauchbar aus. Feldraine zu Mappen finde ich nicht sinnvoll, da ist zu viel Bewegung in der Landschaft. Es mag ja Ausnahmen geben, wo man es machen kann/sollte, aber das muss jeder am Einzelobjekt selbst entscheiden.
Hier http://osm.org/go/0MZBiYCs erscheint jetzt mitten im Acker der Ortsname “Götz”, der war voher nicht dort. Wo kommt der her und wie bekomme ich den wieder weg bzw. an die richtige Stelle in den Ort selbst?
Der kommt von der Teilortsgrenze, MP mit boundary=administrative, admin_level=9, name=Götz. Der Renderer setzt den Namen in etwa in die Mitte des Gebietes. Die andere Beschriftung kommt vom village-place-node. Weiter südlich bei Jeserig übrigens genau dasselbe.
Wenn man den place-node weglässt, gibt es nur noch einen Namen. Den Namen des Ortes kann man ja aus der admin-Grenze beziehen. Der liegt dann aber hier in der grünen Wiese. Nur mit place-node kriege ich ihn an eine bestimmte Stelle (im Ort). Was da “best practice” sei, ist aber ein bekannter Streitpunkt.
Praktisch wäre, wenn man den place-node in das Admin/Grenz-Polynom aufnehmen könnte unter einer Rolle “label”, ”render-hint” oder etwas in der Art. Das ermöglichte dem Renderer, eines der beiden Labels zu unterdrücken.
Oha! Das kannte ich noch nicht. Ich habe bisher noch keine Stadtteile mit boundary=administrative gesehen. Laut wiki sollte das mit admin_level=10 gehen. Spricht etwas dagegen, bei Stadtteilen mit ganz klaren Grenzen dies so zu machen? Die Berechnung des Suburbs durch einen Node mit place=suburb ist naemlich eher suboptimal.
Gibt es auch ein Schema, um ganz allgemein für (MP-)Flächen eine Labelposition vorzuschlagen? Das könnte ich für die Darstellung von Flächen in der Geschichtskarte gut brauchen.
Probier es doch einfach aus.
JOSM wird das wahrscheinlich anmeckern, aber das ist ja zweitrangig.
Ob die Karten, die du als Hintergrund verwendest, diese Information nutzen, vermag ich nicht zu sagen. Alle werden das ziemlich sicher nicht sein. Bei der OSM-Hauptkarte (Mapnik) weiß ich es einfach nicht.
