Jochen Kern (2018-11-12 21:15:07+00:00): 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".