Hi,
der ein oder andere hatte das ja schonmal gesehen das ich eine Auswertung habe für Landuse overlaps oder Landuse/Natural oder Natural/Natural overlaps.
Das ganze hat nach dem Vortrag von @Nakaner auf der FossGIS nochmal Antrieb bekommen und ich habe einige performance issues gefixed.
Jetzt gibt es das für ganz Deutschland (Und Österreich) und nicht nur Bundesland weise.
Hier sind die Debug layer - Das ganze Rechnet immer Donnerstags neu:
Complex
Summe der innenwinkel >4000° bzw >8000°
Ziel ist es komplexe Landuses die sich kilometerweit einer Landstraße hinterherschlängeln oder ähnliches zu identifizieren. Sowas ist einfach Fehlerträchtig.
Hierarchy
Beliebige Flächen überlappen partiell. landuse, natural, leisure, building etc.
Flächen sollen nie “partiell” überlappen sondern immer eine exakte hierarchie bilden. Ein Parkplatz gehört zu einem landuse=retail oder eben nicht. Es kann nicht sein das der nur partiell dazu gehört und die z.b. Nordwestliche Ecke nicht. Ganz drin, ganz draussen, oder ganz umschliessend.
Huge
Aktuell IIRC >200ha und >400ha
Oft macht es sinn solche Landuses zu splitten. Je größer Landuses werden desto anfälliger sind die für unbeabsichtige defekte. Daher macht es sinn die zu zerschneiden.
Natural
Überlappungen von Natural zu Natural oder Landuse.
Overlap
Überlappungen von Landuse und Landuse
Suspicious
Aktuell nur landuses <40m² was ich für ein micromapping missbrauch des landuse keys halte.
Alle “Fehler” nur nach meinem Gefühl und was ich für richtig halte. Das ist nicht konsensfähig aber so mappe ich. Und vielleicht gibts ja den ein oder anderen der das auch für sinnvoll hält.
Vielen Dank. Ich finde das prinzipiell super!
Man muss ja nicht alles, was angezeigt wird, wirklich als “Fehler” ansehen und zwanghaft “reparieren”.
Ein Hinweis meinerseits:
könnte man landuse=grass und landuse=flowerbed und ggf. natural=water ggf. davon ausnehmen? Das sind so Dinge, bei denen typischerweise kleine Flächen auftreten.
Bei huge finde ich den Schwellwert schon für diese recht kleinteilig strukturierte Gegend zu niedrig. Da sehe ich auf Anhieb nur Falsch-positive (oder das was ich dafür halte). Für das Durchsehen fände ich ein Highlighting der Grenzen bei Mouseover oder zumindest beim Anklicken praktisch. Gerade wenn sehr viele markierte nebeneinander sind.
Landuse=grass ist zu 99% unsinn (Siehe auch den Wiki artikel der das Erklärt) grass ist kein landuse sondern es könnte wenn sowas wie eine weide aka meadow sein.
Und nein - Eine Verkehrsinsel ist keine eigene landuse - das ist und bleibt eine verkehrsfläche. Das als landuse=grass zu mappen ist pures mapping für den renderer.
Und flowerbed ist so ziemlich die schlimmste idee für die landuse hierarche gewesen.
Das ist ja kein landUSE - Das ist missbrauch für micromapping und das gehört eigentlich nicht in die landuse tag hierarchie.
Ich komme aus NRW - hier gibts typischerweise keine Felder die 200ha haben. Ich habe hier 2-3 false Positives die sich halt auch nicht splitten lassen. (Militär etc)
Das mag woanders anders aussehen - Es ist ja auch nur ein Hint. Es gibt zeugs das sich halt nicht splitten lässt. Dann sei es so.
Da will ich nicht widersprechen.
Leider nimmt dieses Tagging stark zu, insbesondere wenn man alle Restfitzelchen in “der Map” lückenlos überdecken will.
Ehrlicher wäre vermutlich rendering=green.
natural/landuse und anderes vergleichbares darf nicht mit Linien, vor allem und insbesondere highway verknüpft sein!
Flächen dürfen nicht aus Liniensegmenten (als Relation) zusammengesetzt sein, vor allem wenn es kein Inner gibt…
Multipolygone sollten nur dann angewendet werden, wenn entweder bei outer die technische 2000-Punkte-Grenze erreicht wird und natürlich der klassische Fall, den ich mal mit “See im Wald” umschreibe
Sehr große Multipolygone sollten verkleinert werden → da läuft man zwangsläufig dahin, daß es mitunter zu künstlichen Geometriegrenzen kommt. Wenn man aber z.B. Straßen oder Bahnlinien als “Trennungsgründe” anwendet, wird das schon was. Bei unseren großen Waldbereichen wird das aber mitunter schwierig.
Aber alleine die ersten drei genannten Punkte sorgen für Stabilität… Mit dieser Anwendung hab ich hier in Brandenburg kaum noch signifinante Geometriefehler bei Landuse und vergleichgbarem…
surface ist halt nur ein sekundäres Tag, das die Eigenschaft eines Haupttags beschreibt. landcover=grass wäre mMn das geeignete Haupttag, wird aber nicht gerendert und kaum noch genutzt.
Das prüfe ich auch - allerdings nicht in dem landuseoverlap prozess sondern weiter unten in den wayareaconflicts
Das mache ich auch nicht geometrisch sondern zähle wirklich Anzahl attachte Objekte an einem node und dann gucke ich mir die Objekttypen an.
Aktuell brauche es halt 2 Punkte hintereinander in Linie und Fläche damit ich die auswerfe.
Ich wollte das in einem 2. Layer nochmal erweitern auf einzelne nodes ohne tag. Also einfach wüst beim queren von Flächengrenzen Linien daran anzuschliessen. Völlig unnötig.
Ausnahmen gibts halt für so dinge wie barrier=* oder entrance=* aber ansonsten braucht das nicht verbunden werden. Gerne ja halt die parking nummer wo alle Wege damit verbunden werden was halt null Sinn macht.
Das ist leider eine falsche zusammenfassung. Landcover wird NOCH NICHT genutzt. Das liegt daran das das zwar seit ewigkeiten definiert ist aber nicht gerendert wird. Das führt dazu das alle die halt nur für den renderer mappen das nicht nehmen
Ich setze da auf die Vector tiles die es hoffentlich einfacher machen das wir landcover rendering bekommen.
Ich habe da schonmal kurz drüber nachgedacht mal ein offenes “Wir spielen mal mit Carto-CSS um landcover zu rendern” aufmache - Aber bin nach 2 Tagen überlegen zu dem schluss gekommen das das doch nicht so einfach ist.
natural/landuse und anderes vergleichbares darf nicht mit Linien, vor allem und insbesondere highway verknüpft sein!
das gilt nicht pauschal sondern nur für z.B. highway und railway und waterway, während bei barrier, teilweise natural und anderen Linien die Flächen verbunden werden müssen um eine korrekte Topologie zu modellieren
Flächen dürfen nicht aus Liniensegmenten (als Relation) zusammengesetzt sein, vor allem wenn es kein Inner gibt…
Multipolygone sollten nur dann angewendet werden, wenn entweder bei outer die technische 2000-Punkte-Greze erreicht wird und natürlich der klassische Fall, den ich mal mit “See im Wald” umschreibe
zweimal derselbe Punkt, der m.E. so allgemein nicht zutrifft, der aber in Deutschland überwiegend geteilt wird, soweit ich das aus bisherigen Diskussionen richtig erfasst habe.
Hast du ein Beispiel wo es legitim ist das eine Fläche lateral an einer Linie anliegt im OSM Datenmodell?
Ich kenne keine - Denn es ist ein geometrischer Fehler. Die Linie hat eine dimension von 0 - Wenn du also eine Linie entlang legst sagst du das die Fläche virtuell bis zur mitte dieses Objektes geht.
Selbst das “barrier=fence” ist das ein Fehler. Der ist zugegebenermaßen sehr klein aber defakto hat der “fence” eine dimension die du damit unter den Tisch fallen lässt. Kann man vielleicht bei einem fence vernachlässigen, spätestens bei der barrier=hedge die 1.5m breit ist geht das nicht mehr.
Es ist einfach schlechter Stil und bedeutet eigentlich IMMER einen Fehler. Man kann sich drauf einigen in bestimmten fällen diesen Fehler als “generalisierung” zu ignorieren.
Eine prominente Ausnahme sind admin-Grenzen. Dort ist es sogar “vorgeschrieben”, dass die zugehörigen Segmente der Grenzrelationen separate ways sind, die ggf. in Gebieten mit unterschiedlichen AL mehrfach verwendet werden. Ist in diesem Fall auch sinnvoll, weil es oft vorkommt, dass mehrere Grenzen übereinander liegen und die Grenzen auch die Hintergrundfläche nahtlos abdecken. In diesem Zusammenhang hat es sich auch durchgesetzt, einen eigenen MP-Typ boundary zu verwenden.
Das Arbeiten mit Grenzen gilt aber nicht ohne Grund als nicht ganz einfach.
Wenn man nun aber diese Arbeitsweise für landuse, natural und dergleichen verwendet, ist das beim Erstellen eine gewisse Erleichterung, bei der späteren Wartung, Verfeinerung aber eine Kugelfuhr.
Ich stoße immer wieder auf Gegenden, wo das gebietsweise vorherrscht, meist durch Verfechter, denen das Übereinanderlegen von Linien beim Angrenzen von Flächen nicht gefällt. Ich meide dann halt das Bearbeiten dort.
Selbst das “barrier=fence” ist das ein Fehler. Der ist zugegebenermaßen sehr klein aber defakto hat der “fence” eine dimension die du damit unter den Tisch fallen lässt.
ja, der fence ist so ein Grenzfall wo man auch pingelig sein könnte, und in großen Maßstäben würde man den sogar mit einer Dicke zeichnen, 1:1 zum Beispiel, wobei man für 1:1 nichts weiter findet in den OpenStreetMap daten
da scheiden sich offenbar die Geister, hierzulande wird es bevorzugt einen way für verschiedene Flächen zu nutzen, wenn es dieselbe Kante ist, weil es die Wartung erleichtert. Wenn man separate Linien zeichnet wo es nur eine Grenze gibt, dann muss man diese Linien auch alle einzeln verfeinern (je nach verwendetem Editor gibt es da z.T. auch Mechanismen wo mehrere Wege gleichzeitig bearbeitet werden)
Das ist wohl so, hängt vielleicht auch davon ab, welche Arbeitsweise und welchen Editor man gewohnt ist. Bei Josm ist es kein Problem, mehrere übereinander liegende Linien gleichzeitig zu bearbeiten. Es ist da eher umständlicher, einzelne Linien per Rechts- oder Mittelklick auszuwählen. Mehr als zwei übereinander liegende Naturflächengrenzen sind seltener, bei admin-Grenzen dagegen wird es ja auch anders gemacht.
Ein weiterer Punkt ist, dass in diesen Gegenden gefühlt mehr mit Verkleben oder gar Wiederverwenden von Linien- und Flächenobjekten gearbeitet wird, d.h. ein Straßenstück ist z.B. gleichzeitig Feldgrenze.
Aeh? Wenn ich eine area mit doppeklick in der Fläche mit Josm aktiviere, “w” drücken und verfeinern und natürlich werden dann die benachbarten Flächen die sich die nodes teilen mit erweitert.
.