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

“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)

ich halte es für sinnvoll, vom OGC Standard in manchen Fällen abzuweichen. Wenn ein Zaun eine Fläche begrenzt die als Multipolygon gemappt ist wäre es m.E. Quatsch, den way des Zauns für das MP nicht wiederzuverwenden sondern dafür extra einen neuen way zu zeichnen mit denselben Punkten. Wir haben ein anderes Datenmodell bei dem alle Daten zusammen sind, wir haben keine getrennten Ebenen für Punkte, Linien und Flächen (und das hat auch Vorteile, Stichwort Topologie). Soviele Probleme machen die Flächen eigentlich nicht, mittlerweile hat man sich daran gewöhnt, was uns fehlt sind Kurven :wink:
(OGC hat auch einen Datentyp für gemischte Daten, geometry collection, und auch für Kreise und Kreisbögen, andere Kurven können sie AFAIK aber auch nicht bzw. werden kaum unterstützt. Und es gibt auch Definitionen der OGC für topologische Datenbeziehungen).

Also von Grenzen aufheben halte ich nichts, das macht erfahrungsgemäß richtig viel Probleme. Neulich konnte man die Effekte von fehlenden Limits z.B. in https://www.openstreetmap.org/changeset/116138570 mit 200k Relations member bewundern.

Es gibt aber in der Tat Unternehmen, die ihren eigenen OSM Stack fahren und dort ihre Way Node Limits von 2000 auf einen höhren Wert gesetzt haben. Technisch ist so etwas zumindest nicht unmöglich.

Bis der nächste Neumapper den Zaun löscht (weil nicht mehr vorhanden) und dadurch das MP kaputtmacht. Einzelne Linien sollten m.M.n. nie Teil eines MP sein und schon gar nicht sollte ein MP nur aus Linien mit der Rolle “outer” bestehen. Technisch mag das sauber sein, das Mapping macht es aber kompliziert(er).

Ich habe früher auch auf die von Streckenkundler geschilderte Weise Linien mehrfach verwendet, also z.B. einen Zaun zum Mitglied einer Multipoligonrelation gemacht, bin aber wieder davon abgekommen, da ich gemerkt habe, dass dies die Wartungsfreundlichkeit veringert und die Fehleranfälligkeit deutlich erhöht und ich den zusätzlichen Aufwand, eine Extralinie für den Zaun zu malen, für geringer erachte als die Nachteile, die man damit vermeidet.

dass Zäune abgebaut werden kommt sehr selten vor, leider. Wenn der Mapper den way löscht benutzt er hoffentlich einen Editor der ihn das nicht einfach ohne Warnung machen lässt. Mit iD geht das in diesem Fall nicht wegen des MP und bei Josm gibt es eine Warnung. Der Rest ist nur noch wenig, und davon werden auch ein paar der Programme eine Warnung zeigen.

Zäune werden entfernt weil

  • Weideflächen zusammengelegt werden.

  • Weideflächen nicht mehr für Tiere genutzt werden.

  • dort gebaut wird.

  • er kaputt war und es keinen Ersatz gibt.

Die Möglichkeiten sind vielfältig.

wobei es hier spezifisch um Zäune von Wohngrundstücken Richtung Straße ging