Kritik an meinen Edits - was kann ich besser machen? (Areas vs. MPs)

Das Problem was ich immer wieder sehe ist, daß meiner Meinung nach aus falsch verstandenem KISS MP-Monster gestrickt werden, die für sich nicht mehr KISS sind. Im Ausgangsbeispiel gab es z.B. eine MP-Relation, in der alle Liniensegmente reingekippt worden sind die nicht bei Drei auf den Bäumen sind… Straßen, Wege… egal… rin… Also eine Sammelrelation, z.B. für landuse=residential mit allen beteiligen Liniensegmenten… es mögen vielleicht 7-8 Teilflächen in der Relation gewesen sein, ich hab nicht gezählt… das hat mit KISS nichts mehr zu tun…

Das LowLevel-Datenmodell von OSM ermöglicht ja leider solche vermeidbaren Geschichten…

Sven

Aber ja, ich bin da völlig Deiner Meinung und habe mich vielleicht missverständlich ausgedrückt. Das Beispiel mit dem dem runden/ringförmigen Gebäude und einer Grasfläche, die sich entweder oben auf dem Dach befinden könnte oder aber auch auf Bodenniveau finde ich sehr anschaulich und trifft bei der Frage nach den “aufeinander” liegenden Flächen ins Schwarze. Genau um dieses Problem ging es mir. Die Frage stellt sich mir persönlich bei aneinander grenzenden Flächen überhaupt nicht, da käme ich gar nicht erst auf die Idee, aus den beiden nebeneinander liegenden Flächen aufeinander liegende zu machen.

Insofern hat mir Dein Kommentar durchaus weitergeholfen, also danke dafür!

@ streckenkundler

Zu Deinem Beitrag #83 kann ich mir kein Urteil erlauben … ich habe zwar mal in die OGC-Spezifikationen hineingeschaut, aber das ist keine Materie, die man sich mal eben am Feierabend neben diversen anderen Aktivitäten noch reinzieht. Da muss ich momentan passen, aber trotzdem Danke für den Hinweis, irgendwann lese ich mich da bestimmt mal ein.

@ Tordanik

Danke für die Zusammenfassung in #81 - genau so habe ich es verstanden, Du hast es allerdings professioneller ausgedrückt als ich.

Was das Zerlegen von Flächen zwecks Vermeidung von “Löchern” angeht, war das primär eine theoretische Frage. Ich habe dabei auch weniger z.B. an Gebäude gedacht, als vielmehr an Landuse-Areas. Wenn ich es richtig verstanden habe, sind viele Mapper der Ansicht, dass es sinnvoll ist, große zusammenhängende Flächen in solche überschaubarer Größe aufzuteilen, um eine bessere Bearbeitbarkeit zu gewährleisten. In diesem Fall bleibt doch gar nichts anderes übrig, als willkürlich Trennlinien zu ziehen, oder? Wie Hungerburg schrieb

Wie weit man dabei geht, hängt dann vermutlich wieder vom eigenen Verständnis der Arbeit ab. Ich würde sicher nicht so weit gehen, für jedes Gestrüpp und jeden Tümpel eine umgebende Wiese in Teilflächen zu zerlegen, aber ich würde auch auf keinen Fall einen zig Quadratkilometer großen Wald in einem MP-Monster mit Hunderten von Members erfassen.

Das zu verstehen ist durchaus einfacher, als man denkt, es ist vielleicht nur etwas schwierig, daß rein schriftlich versuchen verständlich darzulegen. Wichtigstes Grundmittel im Kopf ist zu mindestens zu wissen, wie die Mengenlehre in der Mathematik funtioniert… (ich weiß, wie uns die Mathelehrer damit gequält haben, aber recht hatten sie… Mengenlehre dient dem allgemeinen Basisverständnis von fast allem). Das dann hier angewendet auf geometrische Objekte der Form Punkt, Linie und Fläche.

Hier mal die Übersicht (Quelle: https://www.ogc.org/standards/sfa ):

Wir in OSM bewegen uns meiner Ansicht nach nur in den gelb markierten Feldern. Grün ist die datentechnische Ergänzung zu Wissen in welchem Raumbezug wir uns bewegen.

  1. Es gibt Punkte (Point)
  2. mindestens 2 lageunterschiedliche Punkte (vielleicht mit Stützpunkten =vertex), die eine Beziehung zueinander bilden sollen, bilden LineString. Curve im engeren Sinne käme vielleicht hinzu, wenn man auch Splines erstellen könnte.
  3. ist Start- und Endkoordinate dieses LineString gleich ist es ein LinearRing
  4. mehrere separate LineSting bilden einen MultiLineString

in OSM gesprochen:

  1. Punkte
  2. einfache Linien, die keinen geschlossenen Ring bilden.
  3. ist das, was wir in OSM als Fläche bezeichen, es sind nur Linien, deren Start- und Endpunkt gleich sind.
  4. ist alles das, was wir unter allen möglichen Relationtypen verwursten… abhängig davon, was als Typ bei der Relation angegeben wird… (type=multipolygon|bondary|building|node_network|…)

Bei einem echten Datentyp Polygon ist es eine zwingende Vorraussetzung, daß Start- und Entpunkt der Geometrie immer gleich ist, sonst ist das nicht erstellbar.
Bei OSM ist es aber möglich, einen LinieString zu erstellen, der nicht geschlossen ist (=kein LinearRing), diesen eine Eigenschaft z.B. landuse=meadow beizugeben, die aber nur bei geschlossen Geometrien funktioniert. Also Geometriefehler.

Unsere “Multipolygone” leben für mich in irgend einer Zwischenwelt zwischen LinearRing und MultiLineString… Also sowas wie “MultiLineRing” oder so…

Alles, was in der oben gezeigten Übersicht in irgend einer Form mit Surface, Polygon, Triangle, Tin steht, kennt OSM datentechnisch im engeren Sinne nicht.

Sven

Die Frage ist, was Du mit “datentechnisch” meinst, mit Multipolygonrelationen haben wir ja durchaus explizite Polygone und Multipolygone, im Prinzip auch mit area=yes/no auf geschlossenen ways (sowie mit den ganzen tags für die wir uns darauf geeinigt haben, sie als Flächentags zu sehen).

Wir “haben” durchaus Flächen und Polygone, nur dass das bei ways halt nicht auf Geometrieebene definiert wird, sondern erst in Kombination mit den tags klar werden sollte, und es daher je nachdem, welche tags gesetzt wurden und wie man sie interpretiert, nicht immer klar ist, ob eine Fläche oder eine Linie gemeint ist.

Hier in OSM kann man eine “Fläche” oder geschlossene Linienelemente von MP’s in zwei Linien aufspalten (JOSM: zwei benachbarte Stützpunkte wählen und Taste P) Es entstehen zwei Linien. Daran sieht man, daß das eben keine echten Polygone sind, denn bei echten Polygonen geht das nicht.

Das ist ja das Problem, daß das Flächen nicht bereits auf Geometrieebene als Polygon definiert sind… Wenn sie das wären, bräuchten wir für Flächen z.B. keine MP-Relationen für landuse…

Sven

“Es entstehen 2 Linien”? Das ist eine Interpretation, man könnte auch sagen es entstehen 2 kaputte Polygone (bei entsprechenden tags bzw. kaputten Multipolygonen). “Echte” Polygone wird man auch irgendwie kaputt machen können. Es ist eben nicht zulässig, Flächentags auf einem Objekt zu haben, das nicht geschlossen ist (oder ggf. in erster Annäherung ein Punkt).

genau, dann bräuchten wir anstatt einer MP-Relation ein Flächenobjekt, und das würde im Prinzip genauso funktionieren, Linien und Definitionen von outer und inner. Wer mit MPs Schwierigkeiten hat, würde sich bei Flächen genauso schwer tun, dort ein Loch reinzuschneiden, Fehler wären ggf. anders, z.B. falsche Richtung der ways bzw. Grenzen, würde sie aber wohl ebenfalls geben.

Wo sind die OSM-Relationen bei Deiner Zuordnung im OGC-Modell?

Sven

Unsere Multipolygone sind doch den OGC Multipolygonen sehr ähnlich, wenn wir auch etwas toleranter sind, oder? Zumindest ist bei Multipolygonen klar definiert, dass sie eine Fläche beschreiben, Linearirgendwas und Multilineirgendwas passt daher schon beim bloßen Ansehen der Begriffe nicht.

In Bezug auf Flächen z.B. im Sinne von Landuse entsprechen unsere Multipolygone dem OGC-Datentyp Polygon.
Vergleiche das pdf: https://portal.ogc.org/files/?artifact_id=25355 Figure 11 auf Seite 27 mit Figure 17 auf Seite 32.

Edit: Ich schrieb das aber deshalb mit der “Zwischenwelt” da wir in OSM auch rein aus einzelnen Liniensegmenten gebildete MP’s haben, und ein Mix aus beiden… Ein MP mit einem geschlossenen Outer und 1-n jeweils geschlossenen Inner kommen dem OGC-Datentyp Polygon ab nahesten.

Sven

Für das Aufteilen z.B. eines Waldgebiets versuche ich, mich nach Möglichkeit an natürliche Trennlinien zu halten, das wären z.B. durch den Wald führende Wege, Bestandsgrenzen, Schneisen, … Aber natürlich bleibt teilweise nichts Anderes, als die einige Trennlinien abseits einer solchen natürlichen Trennlinien zu ziehen.

Seite 28 oben das letzte Beispiel kann man mit einem OGC-Polygon nicht machen, mit einem Multipolygon schon. Ich schrieb sie wären ihnen ähnlich, weil es ein paar kleine Unterschiede gibt (touching inner rings und Drehrichtung der ways z.B.). Auch Seite 32 zeigt, dass unsere Multipolygone eher den OGC-Multipolygonen entsprechen als den Polygonen. Jedes Polygon kann auch als Multipolygon dargestellt werden, anders rum aber nicht.

Jein… das geht schon, nur heißen die bei mir in ArcGis Multipart-Feature (in QGis ähnlich). Betrifft auch S 32 Fig. 17, Buchstaben b, c, e
Es ist hier dann nur eine Sache der Topologie-Regeln, ob man das zulassen will, oder nicht.

Beim Beispiel S. 32 c wäre ich mir in OSM nicht sicher, ob nicht doch ein Geometriefehler ausgespuckt wird.

An der Stelle vermischt es sich, daß ist richtig. Aber rein aus mehreren separaten Linien zusammengesetzte MP’s passen in keine der OGC-Geodatentypen, die hängen im Nirwana… Um damit zur Ausgangsfrage zurückzukehren: diese aus mehreren separaten Linien zusammengesetzten MP’s (um soche ging es in der Ecke) sind stets vermeidbar und machen beim Editieren bei Dritten nur Ärger. (erst mal außer diese technische 2000-Punkte-Grenze)

Sven

Frederik hat eigentlich schon vor 11 Jahren alles zum Thema OGC-Compliance gesagt: https://help.openstreetmap.org/questions/981/ogc-and-interoperability

Seitdem hat sich daran nichts geändert, und ganz realistisch: daran wird sich auch in den nächsten 11 Jahren nichts ändern, genau aus den genannten Gründen.

Es wird immer mal wieder gefordert, z.B. einen “Area”-Datentyp einzuführen, zusammen mit API 0.7. Dafür gibt es weder Resourcen, noch arbeitet jemand aktiv daran. Auch die neue EWG hat offenbar erstmal andere Prioritäten, weil jeder, der sich das Thema angesehen hat, sofort abwinkt: zu viel Aufwand. Ist einfach so. Du kannst OSM nciht mit ArcGis bzw. ESRI vergleichen, wo eine ganze Horde an Engineers für $$$ Produkte bauen.

Kennt jemand noch das hier?

(aus API 0.7; or, The Whale, by Matt Amos)

Man kann und sollte in OSM aber drauf hinarbeiten, daß unnötige, teils komplizierte MP-Konstrukte so gut es geht vereinfacht und in simple geschlossene Linienzüge umwandelt. Da ist allen mit geholfen und macht die Daten stabiler gegenüber mögliche Fehler.

Sven

Ja, genau so stelle ich mir das vor.

@ mmd

Doll, was man im OSM Universum so alles ausgraben kann, wenn man ein entsprechend gutes Gedächtnis hat … oder aber ein perfekt organisiertes Archiv … ich ziehe meinen Hut … :smiley:

@ streckenkundler

Ich muss mich noch einmal bei Dir bedanken für die Mühe, die Du Dir mit der Darstellung der OGC Standards und den Erläuterungen dazu gemacht hast, auch wenn das deutlich über meinen aktuellen Informationsbedarf hinausgeht. Ich habe die Diskussion zwischen Dir und dieterdreist mit Interesse verfolgt, aber das ist nicht meine Baustellte.

Ich will aktuell in erster Linie hier in meiner Gegend die vielen Datenlücken schließen und die teilweise erheblichen Unschärfen bei den zuvor gemappten Landuse-areas nachbearbeiten, und um da keinen Mist zu produzieren wollte ich zuvor meine Wissenslücken bzgl. MPs schließen. Nicht, dass ich vorhätte, jetzt wie ein Wilder MPs zu produzieren, ganz im Gegenteil, ich stimme dem

voll und ganz zu.

Alles, was darüber hinaus geht, steht momentan bei mir nicht auf der Prioritätenliste, zumal ich ja auch noch ein real life habe und meine Frau ohnehin schon mit der Kündigung droht, für den Fall, dass ich mich auch weiterhin jeden Abend in das OSM-Universum absetzen sollte um da Häusle und Wege zu malen und über Multikultipolygone zu diskutieren … also alles zu seiner Zeit!

Hierzu

mein Vorschlag: Geometriezombies ? :smiley:

Damit werde ich mich aus diesem Topic vorerst mal verabschieden. Nochmals danke an alle, die mir hier weitergeholfen haben!

Ruhig Blut… OSM ist 100% Hobby, Familie geht vor !!

ungeachtet dessen diese OGC-Datenbeschreibung liest sich komplizierter als sie es ist und real angewendet wird…

Wenn wir uns mehrheitlich auf MP’s beschränken, die gemäß Wiki https://wiki.openstreetmap.org/wiki/Relation:multipolygon den Beispielen 1 und 2 entsprechen (*1), haben wir eine passable und sehr gut anwendbare Datenbasis, mit der möglichst viele arbeiten können und die datentechnisch meiner Ansicht nach einfachsten und am stabilsten ist. Alle anderen, im Wiki genannten MP-Relationsformen sind zwar sicherlich möglich, aber für mich zu 100% vermeidbar.

Ich behaupte sogar, daß man sich dann mit allen zur Verfügung stehenden Mitteln dem OGC-Standard hinreichend annähern kann, ohne sich einen Zwang zu setzen, diesen umsetzen zu wollen oder zu müssen. Mit dem OSM-Inspektor (Dickes Danke dafür!!) haben wir ohnehin ein Tool, daß dahingehend die relevanten Geometriefehler zeitnah anzeigt. Die Masse dessen entsprechen in etwa den einschlägigen klassischen Geometriefehlern, die so oder so auftreten können. Sind diese beseitigt, haben wir uns im Rahmen dessen datentechnisch OGC recht gut angenähert. Das reicht durchaus.

Eine Mitteleuropäische Sicht zeigt, wo viel und wo wenig an klassischen Geometriefehlern gearbeitet wird… : http://tools.geofabrik.de/osmi/?view=areas&lon=10.48893&lat=52.45945&zoom=6&opacity=0.62 Einzig bei “Touching Rings” muß man genau schauen, ob es ein Fehler ist, oder nicht, da gibt es gerne FalschPositive Anzeigen.

Sven

(*1): ausgenommen diese technische 2000-Punkte-Grenze (was aber auch nur eine fiktive Grenze ist, die z.B. auch auf 3000 ode 4000 Punkte gelegt werden könnte, wenn es denn die Admins absegnen würden… oder ganz aufheben)