> Sent: Wed, 4 Apr 2018 16:22:05 +0200 > From: "Hartmut Holzgraefe" <hartmut.holzgra...@gmail.com> > To: talk-de@openstreetmap.org > Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets > > Verklebt man Flächen und Wege dann verschwindet eine eigentlich > vorhandene Lücke. > > Stoßen zwei Flächen dagegen tatsächlich direkt aneinander, zB. > ein Waldstück und eine Wiese, dann ist es kein Problem wenn diese > beiden sich eine Grenzlinie teilen. Darum geht es in diesem Thread > aber nicht, sondern konkret um das "verkleben" von Objekten > unterschiedlicher Dimension: zweidimensionale Flächen mit > eindimensional erfassten Stra0en und Wegen.
Ok, das habe ich verstanden. Du hast aber nicht verstanden, dass wir auch die neu gebildeten Flächen wiederum genauer mappen können, wenn wir nur genau genug hinschauen. Und immer wieder ergeben sich dieselben Fragen: Was ist dazwischen, sollten wir nicht eine Lücke lassen? Oder sollten wir die Lücke unterschlagen, weil sie unter gegebenen Umständen nicht relevant erscheint? Vielleicht läuft auf der Waldgrenze ein Weg, der hat, bei genauer Betrachtung eine Fläche, also grenzt dann nicht Wald an Wiese, sondern Wald an Weg und Weg an Wiese, nicht? "Eindimensional erfasst" heißt eben nicht "eindimensional vor Ort". Das Wege, Straßen und Bahnlinien Fläche verbrauchen, wird einem schon dann bewusst, wenn genügend Bäume für Straßen, Wege, Bahn- linien, Stromtrassen, Pipelines, aber auch Feuerschutzstreifen abgeholzt wurden. Nochmal, das Problem ist eines der Abwägung: Wieviel Detail soll erfasst werden und wieviel Detail darf durch Abstraktion verloren gehen!? Wenn der Straßengraben, der ja i.d.R. linear an der Straße entlang läuft, als Teil der (linear erfassten) Straße aufgefasst wird, sprich er mit der Gesamtstraßen-Anlage gemeinsam abstrahiert wird und der Straße eine Standardbreite (oder eine per tag er- fasste) zugewiesen wurde, /dann/ ist es auch eine sinnvolle und effiziente Repräsentation, die lineare Repräsentation der Gesamt- anlage als Flächengrenze wiederzuverwenden. Wie bereits gesagt, entsteht dadurch ein Fehler (abstraktions- bedingt), der bei der Flächenberechnung aber z.B. dadurch min- imiert werden kann, dass (Länge*getaggte Breite)/2 von der Be- rechnung der Flächengröße der geklebten Fläche abgezogen werden kann. /Wenn/ alle Flächen so gemappt würden, dann ist das auch programmatisch einfachst umzusetzen, dann programmiert man das einmal und gut ist. Soll der Straßengraben hingegen als separate Fläche erfasst werden, weil festgestellt wurde, dass die Abstraktion zu stark abstrahiert und oft nicht der Situation vor Ort entspricht, dann braucht man eben ein paar Linien mehr: Die vom Acker zum Graben, die vom Graben zur Straßenkante. Wird der Graben mit riverbank=* erfasst, dann können das schon vier parallele Linien sein: Je nachdem wie genau man hinschaut, lassen sich also mehr und mehr Flächen (und damit auch Flächengrenzen) identifizieren, aber es ist Unsinn, eine Lücke herzustellen, ohne diese dann auch als getaggte Fläche auszuzeichnen. Es steht eine Gesamtfläche zum Mappen zur Verfügung und die Frage ist, wie genau und wo man sie unterteilt, um Teilflächen zu beschreiben. Das kann z.B. grob mit "Harz", "Alpen" oder "Wassereinzugsgebiet der Elbe" geschehen oder etwas genauer mit "Berliner Stadtbibliothek". Weder die (groben) Grenzen von Gebirgen, noch die genaueren der Stadtbibliothek verschwinden dadurch, dass in ihren Gren- zen weitere flächenhafte Objekte identifiziert werden (etwa durch Indoor-Mapping der Stadtbibliothek oder der Erfassung von einzelnen Forstgebieten oder Stauseen im "Harz"). Und auch das Phänomen, dass eine Fläche an eine andere an- schließt, wird sich durch Lückenbildung (egal aus welcher Motivation heraus) nicht egalisieren, wobei es unerheblich ist, auf welcher Detailstufe dieses Phänomen untersucht wird. Man ziehe beispielhaft die naturräumliche Gliederung Deutschlands oder anderer Länder zu rate. Die hier benutzten Grenzen bilden teilweise /Streifen/, die mehrere Kilometer mächtig sind, die auf anderen Detailstufen weitere Flächen enthalten, ohne dabei aber den Aspekt des "aneinandergeklebt"- seins zu verlieren. > > Du kannst den Missstand mit den overlapping ways beenden, > > indem du MP bildest, die sich der geometrisch korrekt > > eingetragenen Flächengrenzen(-teile) bedienen. > > Das verstehe ich nicht, das verkompliziert die Sache doch eher > noch mehr, wie wir an den immer wieder kaputt gehenden > Verwaltungsgrenzen und Küstenlinien regelmäßig leidvoll erfahren ... Das ist zum Teil ein Bildungsproblem. Es ist eben nicht zu vermeiden, dass unerfahrene Nutzer auch mal etwas kaputt machen. Zur Abhilfe gibt es mehrere Kommunikationswege, die Changeset- Kommentarfunktion, das Wiki, etc. pp. - es wäre aber imho falsch, das Datenmodell an der Unerfahrenheit auszurichten, so dass es dann nicht mehr adäquat die Situation vor Ort / am Boden repräsentiert. Ich bin Vereinfachungen gegenüber grundsätzlich aufgeschlossen, wenn sie keine Verschlimmbesserungen darstellen. Wer sich die Tutorials zu den Multipolygonen interessiert und in Ruhe zu Gemüte führt, findet eine allgemeine Lösung für allerlei Flächenkonfigurationen vor Ort. Es lohnt sich, MPs gegen die vermeintlich einfacheren Lösungen zu prüfen, bevor man mit dem Mappen anfängt, leider macht das in der Ungeduld nicht jeder. Die Kompliziertheit in OSM besteht nicht darin, dass MPs schwierig zu verstehen wären, sondern darin, dass sie eines von drei Mitteln der Flächendarstellung sind, alle drei bunt durchwürfelt zu finden sind, sie aber modellhaft und asymbiotisch konkurrieren. Anders gesagt: Es ist weniger bedeutsam, welche Methode Flächen ab- zubilden, genutzt wird. Es sind alle einfach, sofern sie alleinig /einheitlich genutzt würden. Wie Frederik bereits betonte, macht es aber keinen Sinn, dass mit Gewalt durchdrücken zu wollen. Das muss sich evolutionär lösen. Gruß cmuelle8 _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
