OpenStreetMap

Hallo Jochen Kern,

könntest du bitte künftig, Multipolygon-Relationen nur noch anlegen, wenn die Fläche mehr als einen äußeren Ring mit mehr als 1000 Nodes [1] hat oder mindestens einen inneren Ring hat?

Ich habe beobachtet, dass du gerne Flächen gerne als Multipolygonrelationen erfasst, die genau einen äußeren Ring haben und genauso gut mit einem geschlossenen Way abgebildet werden könnten. Diese Mappingweise schadet mehr als dass sie nützt:

1. Multipolygone neigen dazu, kaputt zu gehen, weil nicht alle Editoren vor dem Hochladen die Multipolygone auf Gültigkeit prüfen. Bei geschlossenen Ways passiert das seltener.

2. Zwar mag es auf den ersten Blick sinnvoll erscheinen, sich überlappende Ways zu vermeiden, weil man dann "doppelte Daten" vermeidet. Die Praxis ist aber eine andere. Relationen sind für Datennutzer aufwendiger zu verarbeiten. Um die OSM-Rohdaten in die für das Rendering verwendeten PostGIS-Datenbank zu importieren, muss man die OSM-Datei mehrfach einlesen oder aufwendige temporäre Zwischenspeicher anlegen. Das kostet RAM und/oder Zeit und erschwert die Nutzung unserer Daten. Das ist nicht im Sinne des Projekts.

Wenn man hingegen geschlossene Ways verwendet, genügt es die OSM-Rohdatendatei ein einziges Mal einzulesen, um daraus Linienzüge, die aus einer Liste an Koordinaten bestehen, zu erzeugen (die Art und Weise, wie im GIS-Sektor Geometrien gehandhabt werden und mit der PostGIS, Mapnik & Co. arbeiten).

3. Es fällt nicht nur Neulingen, sondern auch vielen erfahrenen Mappern schwer, in Gegenden mit intensivem Multipolygoneinsatz (manche sprechen dann von "Multipolygonteppichen" oder "Multipolygonitis") Landnutzungsdaten zu ändern. Stattdessen lassen sie die Änderungen bleiben. OSM ist ein Gemeinschaftsprojekt und sollte daher der breiten Masse an Mitwirkenden zugänglich bleiben. Schließlich sind es auch diese, die Fehler korrigieren.

Falls du anderer Ansicht bist, steht es dir frei, obiges in einem geeigneten Forum oder auf einer geeigneten Mailingliste zu diskutieren oder dich über mein Verhalten bei der Data Working Group (data@osmfoundation.org) der OSM Foundation zu beschweren.

Viele Grüße

Michael

[1] Ways können maximal 2000 Nodes haben. Es ist daher legitim, geschlossene Ways mit sehr vielen Nodes durch Multipolygone zu ersetzen.

So habe ich vor langer Zeit auch mal gedacht,
aber das meiste davon hat sich als kompletter
Unsinn erwiesen.

Deine Methode ist die, die mehr schadet als
nützt, weil sie mit "ground truth" nichts zu tun
hat.

Zu deinen Bedenken hinsichtlich der Komplexität:
Wir mappen als Menschen nicht für die Technik
und es ist auch beim aktuellen Stand nicht nötig
hier Abstriche zu machen.

Der Komfort, Multipolygone zu bearbeiten ist lang-
fristig gesehen um Größenordnungen höher und
vermindert den Salat mit "overlapping ways", die
vielfach ein und dieselbe Linie repräsentieren
immens.

Ich habe es aber satt, die Gebetsmühle zu spielen
und Dinge, die sich einem Menschen, der lange
genug darüber nachdenkt von selbst offenbaren,
immer und immer wieder zu predigen.

Vieles von dem was du unten schreibst ist einfach
nicht wahr. Auch die technischen Probleme haben
eher etwas mit schlechter Organisation der Software-
Pipeline zu tun (Stichwort: fehlende oder falsche Vor-
verarbeitung).

Overpass Turbo z.B. beherrscht einen Teil dieser
Vorverarbeitung indem es sowohl MPs als auch
closed ways in areas abbildet / cacht. Leider ist
das in der Praxis immer noch fehleranfällig und
es werden nicht alle Datenobjekte abgebildet
(was sich aber nicht an der Datenrepräsentation
entscheidet).

Ich empfehle dir einmal den anderen Weg zu gehen,
und dich weg von Postgis zu orientieren und einfach
mal zu mappen - insbesondere in Gebieten, wo nach
deiner Methode die Linien vielfach überlappen und
nicht mehr ersichtlich ist, zu welchem der vielen
Gebiete eine Grenzlinie denn nun gehört und sich
die MP Variante im Bild auf eine Grenzlinie begrenzt
und die zugehörigen Flächen in der Mitgliederliste
ablesen lassen.

Deine Bedenken, dass der "arme" Rechenknecht ja
ach soviel zu tun hätte, wenn er MPs beim Rendern
zusammensetzen muss ist "von hinten durch die
Brust ins Auge gedacht", denn

A) Es ist viel einfacher, MPs in closed ways zu
normalisieren als umgekehrt

(MPs, die die Wahrheit vor Ort abbilden, können
aber aufgrund mangelnder Informationen in vielen
Fällen NICHT aus closed ways synthetisiert werden
-- insbesondere dann nicht, wenn die gemeinsamen
Flächengrenzen nicht mal die Knoten wiederver-
wenden, die sie der Realität nach aber durchaus
teilen: Dieser Grad an Schlampigkeit ist mit MPs
gar nicht möglich: Denn, du sagst es selbst, kaputte
MPs werden nicht gerendert: Dieser Fakt ist einer
welcher der Qualitätssicherung DIENT und nicht schadet.)

B) Es ist ohne allzugroßen Aufwand machbar, eine
normalisierte Version eines MP in einer Art Cache vor-
zuhalten (und das dann für das Rendering zu verwenden)
und diesen Cache auch nur dann zu aktualisieren, wenn
sich das MP ändert.

(Oder anders gesagt: Der Aufwand des Zusammensetzens
von MPs ist einer, der sich 1x on_change erledigen lässt
und für viele Anwendungen nicht jedes Mal erneut errechnet
werden muss; hier fehlt aber ein Stück in der OSM-Infra-
struktur oder z.B. in der API, die diese derived_data aus-
liefert; es ist aber der falsche Weg, aufgrund dieses
Missstands ein sauberes Datenmodell in Frage zu stellen,
das funktioniert und das gegen eine Krücke auszutauschen,
die nicht funktioniert, weil sie die Realität nicht richtig ab-
bildet).

Gruß

ps: Es ist mir klar, dass die nächste Mail von dir, die raus-
geht einfach nur deine Argumente wiederkäut. Ich erwarte
auch nicht, dass du die Argumente oben verstehst und an
der Seite kämpfst, dass Multipolygone oder allg. ein Flächen-
typ endlich besser und unmissverständlicher unterstützt
würde, vom Projekt.

Vielmehr sorgt deine Ideologie dafür, dass (aufgrund falscher
Annahmen) ein mathematisch einfaches (sofern man sich
nicht partout dagegen verschließt, weil es ja nicht sein darf,
dass Mathematik hübsch ist) Datenmodell für die geo-
metrische Repräsentation realer Objekte, dem GLAUBEN
geopfert wird, es sei datentechnisch schwer zu verarbeiten.

Das ist es nicht, aber es gibt eben Kräfte, die genau das
propagieren. Weil man mit schlechten Algorithmen und
schlechter Mathematik viel mehr Material braucht, ein
gegebenes Problem zu lösen, als ohne. Oder kurzum:
Mit der Unwahrheit lässt sich einfacher Geld verdienen.

MPs sind ein ALTER HUT, ihre Mathematik hat mit OSM
gar nichts zu tun, sie wurde lange vorher definiert und das
Projekt hat sich diese irgendwann zueigen gemacht (weil
ein Flächendatentyp _fehlte_). Sie sprangen in eine Nische,
die besetzt werden musste. Es ist unsinnig sie zu verteufeln,
nur weil man sie nicht versteht (das trifft auf Design und Ver-
arbeitung gleichermaßen zu).

Bitte sieh in Zukunft davon ab, mir weiterhin diesen Schmus
unten zu schicken und beschäftige dich stattdessen damit,
wie MPs softwaretechnisch besser unterstützt werden können.
Das ist zukunftsträchtiger, als sich bequem darauf zurück-
zuziehen, dass "das nicht sein darf".

Hallo Jochen,

ich hatte gehofft, dass mein erster Kommentar, der keine Drohung enthielt, dich auf den rechten Weg zurückleitet.

Du seist hiermit darauf hingewiesen auf die Sperre des Benutzers SHARCRASH von vor etwa zwei Jahren hingewiesen: https://www.openstreetmap.org/user_blocks/1084

Falls du dich von dieser Nachricht gestört oder eingeschüchtert fühlst, steht es dir frei, dich im deutschen OSM-Forum über mein Verhalten zu beschweren oder dich an die Data Working Group der OSMF (per Mail unter data@osmfoundation.org erreichbar) zu wenden.

Viele Grüße

Michael

Ein Nachtrag: Ich hoffe, dass dir der bekannt ist, dass der Begriff "Multipolygon" im OGC-Kontext eine andere Bedeutung hat als im OpenStreetMap-Projekt.

Es fehlen nur noch ein paar Worte, bevor ich dich in die Kategorie "Troll" stecke.

Deine Nachrichten sind eine einzige Drohung, denn sie zielen darauf ab, mein Mapping-Verhalten mit dem von dir gewünschten gleich zu richten.

Außerdem propagierst du wiederholt die Unwahrheit. Es mag Abweichungen zu OGC geben, die sind aber minimal und rechtfertigen daher nicht die Aussage, dass der Terminus eine andere Bedeutung hätte. Korrekt wäre, dass die Multipolygon-Definition in OSM mit der in OGC nicht ident ist. Aber auch das ist nicht in Stein gemeiselt und änderbar!

Es war mir völlig klar, dass du meine Worte nicht überdenkst und einfach deine Meinung iterierst. Sie hat aber mit den Gegebenheiten dieser Welt nunmal nichts zu tun.

Sperren, Abmahnungen, Drohungen, Folter, Wegelagerei waren in allen Zeiten der Menschheit beliebte Mittel um die Wahrheit zu unterdrücken. Ich verstehe nicht, warum du dich als halbwegs gebildeter Mensch ebenso auf diese Methoden einlässt, anstatt das eigene Verhalten zu überprüfen und die Belästigungen von Mappern einzustellen.

Es ist ein Unterschied, ob du beispielsweise verschiedene Meinungen in der Wochennotiz /darstellst/, oder aktiv ein bestimmtest, /dir/ missliebiges Mappingverhalten zu unterdrücken versuchst, dass aber nachgewiesenermaßen korrekt und langfristig stabil ist.

Wenn du spätestens jetzt nicht anfängst, selbst zu denken und beim Team für Benutzersperren dein Unwesen treibst bzw. dort deine Zustimmung erteilst, dann viel Spaß mit dieser Form einer Inquisition. Deine Sachargumente habe ich geprüft und als nicht zutreffend bewertet.

Gruß

Eine Empfehlung: Schreibe an osm-dev und fordere die Revidierung der OSM-API, so dass diese endlich einen dedizierten Flächentyp unterstützt. Das macht diese ganze Diskussion hier überflüssig, und unzählige andere nutzlose, weil ständig wiederkehrende gleich mit.

Eine weitere Empfehlung: Begriffe wie der "rechte Weg" sind bedeutungstechnisch überladen. Sie werden im religiösen Zusammenhang sowie Sekten, aber u.a. auch im politischen Umfeld verwendet. Falls das deine Übersetzung der im englischen OSM-Wiki formulierten "best practices" gewesen sein soll, dann ist es eine unglückliche.

Das Projekt kennt "Empfehlungen", die an die freiwilligen Mitstreiter gerichtet sind, aber keine "rechten Wege".

Um die Kritik abzurunden, möchte ich außerdem noch auf ein Gedicht von Franz Werfel verweisen:

https://web.archive.org/web/20181116183038/https://lyrik.antikoerperchen.de/franz-werfel-der-rechte-weg,textbearbeitung,518.html

Gruß