[Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

Martin Koppenhoefer dieterdreist at gmail.com
Fr Apr 20 12:38:25 UTC 2012


Am 20. April 2012 14:01 schrieb Christian Müller <cmue81 at gmx.de>:
> Am 20.04.2012 03:14, schrieb Martin Koppenhoefer:
>> Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als
>> auch für die zukünftige Pflege bei Daten im Vergleich zu einer
>> site-relation als bunte Mischung aller möglichen Elemente und
>> Bestandteile ist ein schlichtes Polygon, das die Gesamtfläche
>> beschreibt.
> Das sie implizit durch mehrfach als Ringelemente verwendete ways vorhanden
> ist, war mir klar - das ist aber dennoch nicht das gleiche.


+1


> Sammelvariante:
>    Eine Anfrage nach den Teichgeometrien innerhalb des Schlossparks ist
> durch lookup in die Relation zu lösen.
> Boundary-Only-Variante:  (also nur die outers des Schlossparks)
>    Man benutzt die Grenze des Schlossparks zum Verschneiden und sucht sich
> in den verbleibenden Daten die Teiche raus.


genau, funktioniert immer, sofern die Grenzen aussen geschlossen ist,
erfordert keine Relationen, und findet alle Elemente, nicht nur die,
die ein Mapper eingetragen hat. Ausserdem sind Datenbanken mit
Geofunktionen u.a. genau für Anfragen dieser Art optimiert.


> Bezogen auf einen kleineren Park ist der Aufwand für beide Varianten sicher
> vernachlässigbar.  Für ein größeres Gebiet ergeben sich mit der
> Sammelvariante aber Vorteile - da man nicht verschneiden muss.


da man einer händisch erstellten und von zig Mappern (davon die
überwiegende Menge keine Experten, manche auch Anfänger oder
Wenigmapper, manche arbeiten auch mit Tools ohne Unterstützung für
alle Relationen, d.h. sie sehen evtl. nicht einmal in ihrem Editor,
dass ein Objekt, das sie bearbeiten evtl. Teil einer site-Relation
ist, oder sie halten nichts von Site-Relationen und fügen ein Objekt
das sie erstellen absichtlich nicht dazu, etc.) weiterbearbeiteten
Relation sowieso nicht wirklich trauen kann, würde ich selbst wenn es
die Relation gibt mich lieber auf die geographischen Gegebenheiten
verlassen, als auf die Relationenzugehörigkeit einer site-Relation.


> Es gibt natürlich auch Probleme:
> z.B. könnten die Relationen schlecht gepflegt sein und man erwischt nicht
> alle Ergebnisse, die man mit einem Verschnitt erhalten hätte.


+1, s.o.


>  Andererseits
> könnte ein Verschnitt sehr komplex werden - wenn das MP aus mehreren
> Einzelflächen besteht, also mehrere Verschnitte berücksichtigt werden
> müssen.


dann werden die eben der Reihe nach abgearbeitet. Davon bekommst Du
normalerweise gar nichts mit, die DB spuckt das Ergebnis aus und
fertig.


> Mir ging es darum, aufzuzeigen, dass egal wie man das Kind nennt -
> type=collection, type=site, type=multipolygon - im Endeffekt über den
> Flächenbezug gesprochen wird.


-1, multipolygon unterscheidet sich hier von site und collection
dadurch, dass es nur eine Fläche definiert, während die anderen eine
Gruppe definieren, die nicht notwendigerweise räumlichen Bezug haben
muss. Z.B. könnte man einer site-Relation ein Ticket-Office zuordnen,
das ausserhalb der site liegt. Eine "collection" (und auch eine
"site") kann alles enthalten, nodes, ways, Flächen, Relationen.
Theoretisch müsste eine Relation überhaupt keine Geometrie haben und
könnte trotzdem Sinn machen (weil sie als member in einer anderen
Relation sitzt. So was haben wir bisher allerdings nicht oder kaum in
der db, und ist auch mit unseren (Editier-)Mitteln eher schwer in
Schuss zu halten).


> Ich habe jetzt nicht nachgeschaut, aber ich
> schätze Du findest Sammelrelationen aller Kreisgrenzen pro Bundesland - sie
> bilden genau das ab, was auch ein nestedMP abbilden würde.


das hoffe ich nicht, wäre ja komplett überflüssiger Ballast, ich denke
aber, dass es üblicherweise auch nicht so ist.


> Erhält ein Datenverwerter (e.g. renderer) diese MP, überlappen die Flächen
> nun - entweder der Schlosspark wird als monotone Fläche opaque über die
> Einzelflächen gezeichnet, oder darunter.  Für einfache Sachen (etwa
> "buildings on top of landuses") kriegt ein Renderer das per Regel hin, ob
> das aber für jeden denkbaren Fall von (sinnvoller) Verschachtelung der Fall
> ist?


hast Du Dich schonmal mit den Render-Regeln von Mapnik
auseinandergesetzt? Da spielt es bei den Flächen kaum eine Rolle, wie
die getaggt sind, die sortiert er nach Größe (innerhalb desselben
Layers, nicht alle Flächen sind in einem Layer). Es gibt aber auch
überhaupt keinen Grund, Flächen grundsätzlich gefüllt darzustellen,
manches macht als Grenze mehr Sinn. Wie gerendert wird, hat mit der
Dateneingabe also dem Modell, wie die Welt in der  DB abgebildet wird,
nicht so viel zu tun.


> Je nachdem, welches Thema ein Renderer hat, müssen nicht alle Sichten auf
> diese Einzelfläche dargestellt werden.  Wären Flächenlinks innerhalb der
> Relation vorhanden, könnte ein Datenverwerter allerdings durch die schiere
> Anwesenheit von Flächenlink-Mitgliedern erkennen, ob mehr Detail vorhanden
> ist.


mehr Detail von was? Dein Vorschlag zielt darauf hinaus, alles was
sowieso schon über räumliche Bezüge verbunden ist, nochmal mit site-
und collection-Relationen zu verbinden, im Endeffekt die komplette
Datenbank von OSM ( -->site name=Earth), und alle denkbaren
Verknüpfungen und Bezüge die vielleicht jemanden interessieren könnten
schonmal vorab in Relationen anzulegen. (Dein Schloss könnte z.B. auch
in einer Site "Schloß Rotzingen und Umgebung" stecken, oder
"Ausflugsziele um Hintertupfingen"? und vielleicht will man da auch
noch Eisdielen mit drin haben?).


> Stellen wir uns stattdessen vor, dass wir gern die Anzahl aller Parks
> innerhalb D, die mindestens x Teiche haben (x=0,1,2,3,...), wüssten.
>  Overpass holt uns alle leisure=park MPs - hätten wir (geometrisch nicht
> relevante) Flächenlinks in diesen MP, wäre der nächste Schritt eine einfache
> Iteration ohne geometrische Berechnungen.


s.o. Stell Dir vor, jemand hat nicht nur die Teiche sondern auch die
Mülleimer, die Bäume und größere Steine gemappt, und in die
Site-Relation gepappt. Diese site-Relationen werden je nach Detailgrad
immer größer und die Wahrscheinlichkeit, dass jemand da versehentlich
was rauslöscht oder nicht einfügt ist riesig (d.h. man kann sich
sowieso nicht auf das Ergebnis verlassen, selbst wenn die Teiche und
Schlossparks in OSM drin sind). Sobald man da was ändert, z.B. einen
Member splittet, müssen alle die eine Datenkopie aktualisieren wieder
die komplette Relation in ihrer Kopie einspielen, ...


> Implizit geht es auch, aber es
> ist um ein vielfaches aufwändiger - alle Daten jeder bbox für jedes
> leisure=park MP müssen geholt, verschnitten und auf Inklusion geprüft
> werden.  Das wäre der Unterschied zwischen beiden Varianten..


genau. Letzteres macht die DB automatisch (sie ist räumlich
organisiert und daher optimiert für solche Anfragen), ersteres
scheitert am Problem, dass es nur funktioniert, wenn alle Mapper
perfekte Daten produzieren (d.h. die Site-Relation immer auf aktuellem
Stand ist und es keine Teile gibt, die drin sein sollten aber nicht
sind). Zusätzlich produziert ersteres einen riesigen Overhead und
funktioniert nur für Dinge, die ein Mapper per Relation als
zusammengehörig definiert hat. Da man die Welt unter unendlich vielen
Gesichtspunkten betrachten kann, könnte man auch unendlich viele
solcher Sammelrelationen anlegen.

Ein ziemlich ähnliches Thema:
http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

Gruß Martin




Mehr Informationen über die Mailingliste Talk-de