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

@Map_HeRo

Ja, man könnte Flächen mit Löchern theoretisch auf diese Weise darstellen. Und wenn man die zerlegten Flächenteile dann in eine MP-Relation packt, wäre das Resultat sogar inhaltlich äquivalent zu unseren heutigen MPs. Man hat sich per Konvention dagegen entschieden, das zu erlauben, weil es beim Auswerten etwas nerviger ist (man muss z.B. darauf achten, beim Rendern überschüssige Umrandung an der Trennkante loszuwerden) und weil die Willkürlichkeit der Trennkante auch irgendwo unschön ist, aber letztlich wäre es kein Hexenwerk, mit solchen Daten umzugehen und dieselben Ergebnisse zu erzielen wie heute.

Von den Schlussfolgerungen her scheinen mir deine Überlegungen auch richtig. Ich störe mich aber konzeptionell etwas daran, dass so oft von “aufeinander” liegenden Flächen die Rede ist, auch wenn das vermutlich nur eine andere Formulierung desselben Sachverhalts ist. Denn eine Grasfläche im Innenhof eines als MP gemappten Gebäudes liegt natürlich gar nicht auf der Gebäudefläche – das Loch gehört per Definition ja gerade nicht zur Gebäudefläche dazu.

Ich hätte es so formuliert: Ein MP ist nötig, wenn eine Fläche ein Loch hat. Ob in diesem Loch dann noch eine oder mehrere andere Flächen liegen, ist dafür egal.

Es ist nur in dem Sonderfall, dass das gesamte Loch von exakt einer anderen Fläche ausgefüllt wird, aus Komfortgründen üblich, diese Fläche als inner des Multipolygons zu nutzen, statt einen neuen, tag-losen Way als innere Grenze der MP-Fläche zu zeichnen. Aber dennoch hat die Wiese im Innenhof keinen engeren Bezug zum Gebäude als die Wiese vor dem L-förmigen Gebäude.

Nein.

Das Grundproblem ist, daß wir in OSM noch immer keinen echten Datentyp “Polygon” nach OGC-Spezifikationen haben. Ich frag mich sowieso, warum das so ist… Meiner Ansicht nach wäre es längst überfällig gewesen, diesen Datentyp einzuführen.

Bei allem, wo wir in OSM über Multipolygon im Sinne See als “Loch” im Wald drumherum reden, ist das alles Simpel ein Polygon und kein Multipolygon im Sinne OGC…!!! Da gibt es geodatentechnisch ziemliche Unterschiede: vergleiche Klassen-Hierarchie hier Seite 14 und Erläuterungen nachfolgend. Wir in OSM bewegen uns mit unseren “Flächen” im Bereiche LineString/MultilineString oder so…

Wir wollen schön opendata sein und haben, schaffen es aber nicht, uns auch geodatentechnisch weiter an OGC anzunähern… :expressionless:

Je mehr aber Gebiete dicht und kleinteilig gemappt werden, je mehr unterschiedliche Dinge hinzukommen, desto mehr muss man sich Gedanken um eine Erweiterung des Modells der verschiedenen Geodatentypen machen… Zu dieser Überzeugung bin ich kurz nach meinem Einstieg bei OSM gelangt und wäre dringend nötig…

Solange aber daran nichts grundlegend geändert wird, werden wir immer wieder epische und zu keinem Ergebnis führende Disskussionen haben über Multipolygonwahnsinn und Co. auch wie diese hier… Die diversen anderen langen Forenbeiträge sind bekannt…

Grundsätzlich bin ich hier der Meinung, daß es möglich ist eine gute Datenefassung zu erreichen, ohne daß hochkomplexe komplizierte MP-Relationen erstellt werden, wo zum Schluß vielleicht nur noch der Ersteller durchsieht… Weniger ist mehr…

Sven

…mal an den Grundfesten rüttelnd…

Über MPs mit inner/outer hat sich schon mal jemand Gedanken gemacht, und die lösen das Problem dahingehend UND zufriedenstellend UND (weitgehend) KISS, dass man sich eigentlich keine Gedanken über ein anderes wahrscheinlich komplexeres alternatives Modell machen muss.

Wenn ich hier mitlese, dann muss ich unweigerlich ans Karwendel denken: Es gibt dort ein paar vorherrschende Kategorien, natural=bare_rock|scree|scrub, landuse=forest. (Nebenbei würde ich hier natual=wood bevorzugen.) Das ganze wurde so gemappt, dass keine Kante doppelt gezogen wird, sondern dass die Kanten anonym bleiben, aber verschiedenen Multipolygonen zugehören. Ein richtigs Kunstwerk, an dem ich mich schon ordentlich verbrannt habe, ein paar Quadratkilometer Wald ausgeblendet, weil sich irgenwo etwas überschnitten hat. Es setzte aber auch schon ein Kompliment von einem andren local dafür, wenn ich die Ausdehnung der MPs ein wenig reduziert hab.

Man kann damit nette Dinge machen, zB die Nord- die Vomper- und andere Ketten, das sind geographische Bezeichnungen, in einer MP Relation namentlich abbilden. Wenn ich die Idee aber weiterspinne, dann ist die ganze Welt ein einziges MP, und das wünscht sich glaub ich niemand.

Hab das schon eingesetzt, a.k.a. Schalenmodell. Das geht in OSM-Carto gut bei Kategorien, die keinen Rand rendern. Wenn ich recht erinnere, dann gibt es auch einen Carto-issue, der drauf abzielt, Ränder zu unterdrücken, wo sie nicht erwünscht sind.

Die Aussagen mit “drober|drunter” kommen von der Malerei. Wie viele OSM-Konten heißen “CartographerNN”? Mapper die meinen, sie zeichnen eine Karte. Wie anders soll man Mapper aber übersetzen, als mit Kartograph? Ich mal die Wand grün, dann setz ich mit Deckfarbe ein paar gelbe|rosa|graue|usw. Tupfer “drauf”.

Auch das “Loch” ist nicht ganz frei von der Malerei. Denn es ist ein “inner” und kein “outer”, und das outer definiert, wo es aufhört!

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