[Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel

Christian Müller cmue81 at gmx.de
Do Sep 29 18:46:19 UTC 2011


Am 29.09.2011 17:26, schrieb Martin Koppenhoefer:
> wenn wir einzelne Pflastersteine mappen würden, dann klar ja. Wenn man
> "die Pflasterung" mappt gehört Sand und Stein zusammen.

Was, wenn ein anderer Mapper das anders sieht?
Was, wenn jemand Sand und Stein getrennt mappen möchte?


>   Aber die
> wenigsten würden auf die Idee kommen, den Grasstreifen daneben
> absichtlich auch noch miteinzuschließen.

Das kommt darauf an, wovon "die wenigsten" reden.  Wenn sie von der 
Straße reden und den Grasstreifen als zugehörig empfinden, schließen sie 
den "absichtlich"  mit ein - wo Grenzen liegen, legt die 
Abstraktionsebene des Wortes fest, dass Du verwendest, um ein Ding der 
Realität zu identifizieren.  Und je weiter sich die Abstraktion vom 
"Sandkorn" entfernt, desto schwieriger wird es, sich über "das gleiche" 
zu unterhalten - es ist nicht klar, ob der Grasstreifen daneben mit 
einzuschließen ist, oder nicht, nur weil /Du/ eine eigene Auffassung 
dazu hast.  Für /Dich/ ist es klar und wenn Du daheim an deinem eigenen 
kleinen Abbild der Realität bastelst, würde es auch niemanden 
interessieren, ob deine Auffassung zur Auffassung eines anderen passt.  
OSM = viele Auffassungen.  Die Zähflüssigkeit mit der auch nur ein 
einziger Konsens gefunden wird, demonstriert Dir, wieviele tatsächlich 
auf die "Idee kommen würden, den Grasstreifen daneben mit einzuschließen."


>> Die Frage muss sein, welchen Sachverhalt der Realität man abbilden möchte.
>>   Will ich den Sachverhalt, dass ein Wald an die Straße grenzt (was nur eine
>> grobe Aussage zur Lagebeziehung ist, und immer sein wird, aber das kann ich
>> eben modellieren)
> wie schon erläutert ist das durch die Lage bereits klar (Stichwort
> Geodatenbank).

Wie schon erläutert, täuschst Du dich da.  Geometrische Lage und 
Topologie sind nunmal verschiedene Dinge und wenn Du letzteres aus 
ersterem Ableiten möchtest, musst Du rechnen und brauchst Regeln, teils 
sehr aufwendige.  Das führt uns wieder zu deiner ureignen Auffassung der 
Siedlungsfläche - dem einzigen Ding, dass Du nicht feingranular erfassen 
willst, weil man es nicht automatisch zusammenrechnen kann.  Was Dich 
aber nicht davon abhielt, zu behaupten, alles andere sei "einfach" 
zusammenfassen.


>   Wenn Du den Wald an seiner Grenze erfasst hast und
> feststellen willst, ob eine Straße innerhalb der nächsten 50 m ist,
> dann musst Du nur die Ausdehnung des Walds um 50 m erweitern (in
> Deiner Abfrage, nicht in der OSM-Datenbank) und sehen, ob sich Straßen
> darin befinden. Wenn Dich auch Straßen interessieren, die innerhalb
> von 30 oder 100 m liegen, dann kannst Du auch das abfragen: Du
> entscheidest selbst, bis zu welchem Abstand die Straße noch "am Wald"
> läuft.

Ja, super und dabei kommt dann totaler Müll raus:  Einmal verschiebe ich 
dann eine Grenze, die auf dem Weg liegt, ein andern Mal eine Grenze die 
daneben liegt.

Sorry, wenn sich im ersten Schritt nicht darauf geeinigt wurde, /wie/ 
ein Sachverhalt der Realität abzubilden ist, kann ich den Fehler nicht 
damit korrigieren, dass ich ein /offset/ benutze.  Ein Datenbrei lässt 
sich mit einem /offset/ nunmal nicht verbessern.  Damit wird nur 
verschoben, was ursprünglich schon zusammengemanscht wurde - bei der 
Erfassung, durch die vielen unterschiedlichen Auffassungen von 
MapperInnen, durch unklare Dokumentation im Wiki, etc..

Ich kann nicht, in der Phase der Auswertung, höhere Genauigkeit from 
nowhere "erzeugen", als das, was in den Ausgangsdaten steckt.


> .. schon längst
> einen workaround (highway=residential) geschaffen.

"workaround" - Du sagst es.


>> oder möchte ich den Sachverhalt ausdrücken, dass zwischen
>> etwas und etwas anderem immer noch ein drittes etwas ist  (das ist Leibniz -
>> "egal wie klein der Raum wird, ich kann ihn immer nochmal in zwei Teile
>> teilen").  Letzteres können wir mit OSM nicht modellieren, da wir dazu
>> unbegrenzte Genauigkeit bräuchten, eine Grenze zu erfassen - die haben wir
>> nicht.
> das stimmt so nicht: wenn klar ist, was alles zu einem bestimmten
> Flächentyp gehört

Das ist NIE klar, weil auch deine Defintion immer eine begrenzt genaue, 
oder bewußt ungenaue ist.  Z.B. durch Worte "überwiegend", "vorrangig", 
"grob", "in etwa"  oder auch "Straße", "Wald", etc.  das sind nunmal 
alles begrenzt genaue Begriffe.  Und alle Versuche das penibel genau zu 
spezifizieren, enden in einem Haufen, den Du immer größer machst - jedes 
Mal, wenn jemand mit einem "aber" ankommt.  Du kannst keine sinnvolle 
Granularität festlegen, mit der jeder glücklich ist - zeigen Dir das 
nicht mittlerweile die Jahre deiner Beharrlichkeit und der Fakt, dass 
nicht jeder auf der Granularität mappt, auf der Du mappst?  Was Du 
machen kannst, ist den Leuten eine Struktur an die Hand zu geben, die 
nach oben und nach unten (granularity-wise) funktioniert, _ohne_ selbst 
zu wissen, wo die Granularität liegt, die jemand (Joe mapper) mit einer 
Instanz dieser Struktur erzeugt.


> , (s. oben Pflasterung vs einzelne Pflastersteine),
> dann kann man nicht immer noch etwas erfinden, was dazwischen passt,
> sondern dann gehört es zum Modell, dass die Bordsteinkante mit der
> Kante der "gepflasterten Fläche" verbunden ist.

Genauso wie mich alles das, was /Du/ zwischen Wald und Straße erfindest 
oder schon erfunden hast, nicht notwendigerweise interessiert!

Wenn ich deine Worte benutze:  Wir haben das Wiki.  Dann kannst Du nicht 
kommen und noch etwas erfinden, was zwischen Straße und Wald passt!  
Also ist die Straßenkante bis in alle Ewigkeit mit der Waldkante 
verbunden.  Du kannst nicht immer noch etwas erfinden, was da dazwischen 
passt!  Der Straßengraben ist eben nicht Teil des Modells, also geht er 
_entweder_ in der Waldfläche _oder_ in der Straßenlinie unter.  Sorry, 
aber für Dich können wir das Datenmodell nun nicht extra nach unten 
anpassen, nur weil Du den Straßengraben extra erfassen willst.

Oder anders herum:  Sorry, weil ich jetzt den Straßengraben erfasse, 
können Leute echt nicht mehr erwarten, ihre groben Bezüge zwischen 
Straße und Wald in der DB repräsentiert zu sehen..  Schließlich können 
die sich ja das, was das Datenmodell früher mal modelliert hat, "ganz 
einfach" selbst ausrechnen.  --  Wenn man mal darauf vertraut, dass Du 
auf dem MICROmapping-Level keine Fehler produzierst, die dieses Ergebnis 
verfälschen.


>> Wir kommen in OSM nicht umher, eine Struktur zu benutzen, um sowohl die
>> etwas gröberen Abbilder, als auch die sehr detailierten (aber immer noch
>> begrenzt genauen) Abbilder der Realität, welcher MapperInnen zusammentragen,
>> zu verwalten.  Diese Struktur ist, wenn es um Flächen geht, schon vorhanden,
>> sie heißt Multipolygon.
> nein, ein Multipolygon hat nichts damit zu tun, wie detailliert oder
> grob die Daten sind.

Eines nicht, aber mehrere!

Wie detailiert oder grob ein Datum ist, kann ich nur im Bezug auf ein 
anderes Datum sinnvoll ermitteln.

Und würdest Du nicht auch zustimmen, dass ein 'outer' ein gröberes 
Gebiet umreißt, als seine 'inners'?  Und das 'inners'  von 'inners' 
eines outer noch fein granularer sind?


>   Sie ist in diesem Kontext nur eine etwas
> elegantere Methode, überlappende Ways zu vermeiden und dafür einen
> einzelnen Way mehrfach zu verwenden (weiterhin ermöglichen sie,
> mehrere Flächen als eine zu definieren und Flächen abzuziehen).

Wenn Du meine Datenhaltungsmail verstanden hättest - offensichtlich habe 
ich sie nicht verständlich genug geschrieben - wüßtest Du, dass 
Multipolygons (/mehrere/ davon) in der Lage sind, viel mehr zu leisten:

         Sie sind die Möglichkeit schlechthin, Flächen in Bezug zu setzen.

         1 MP - setzt eine oder mehrere 'outer'-Flächen in Bezug zu null 
oder mehreren 'inners'

         Nun stell Dir einen Park innerhalb eines Wohngebietes innerhalb 
einer ganzen Stadt innerhalb eines riesigen Waldgebietes vor.

         1. MP) Waldgebiet mit 'outer' Grenze
         2. MP) Stadt (Siedlungsgebiet) mit 'outer' Grenze
         3. MP) Wohngebiet mit 'outer' Grenze
         4. MP) Park mit 'outer' Grenze

         -> Alles sind Flächen, alles sind Multipolygone
         -> nun die Bezüge (das kann ein anderer machen, wenn Du dich 
nicht traust :o)  )

             2. MP ist Mitglied von 1. MP in der Rolle 'inner'
             3. MP ist Mitglied von 2. MP in der Rolle 'inner'
             4. MP ist Mitglied von 3. MP in der Rolle 'inner'

         -> wenn im Nachhinein die Flächengrenze der Stadt korrigiert 
werden soll, muss auch nur das 2. MP mit seinen basisgeom. Kindern 
geladen werden.  Die Flächengrenze erscheint im Editor und kann editiert 
werden..  Etc. pp.

         -> jetzt sage mir, was daran kompliziert ist, oder was daran 
mehr Ressourcen fressen würde, als die Erfassung des gleichen 
Sachverhalts mit zigtausend closed+overlapping ways..


>>   Sie wird bereits mal dort und mal da in begrenztem
>> Kontext eingesetzt, sie aber als /das/ verbindende Element zwischen MICRO-
>> und MACROmapping Welten zu begreifen, fehlt.
> weil das damit auch nichts zu tun hat. M.E. sollten wir uns auf das
> Micro konzentrieren, da das Macro sich aus dem Micro errechnen lässt.

Du kommst nicht davon los, ich sehe schon.  Aber das ist "d.E." - auch 
wenn das jetzt fiest klingt, aber überlege mal, was Du da sagst:  Du 
glaubst tatsächlich den Schlüssel in den Händen zu halten, wie sich das 
Macro aus dem Micro zusammensetzt - das kann ich Dir nicht abnehmen.

Das ist in etwa so, als wenn Du behauptest, alle Teile eines Autos 
lassen sich immer nur auf eine bestimmte Art zusammensetzen, ohne den 
Bauplan (die Struktur) zu kennen.  Vielleicht hättest Du, bezogen auf 
diese schwache Analogie, sogar bei einigen Modellen recht, aber Du wirst 
mir zustimmen, dass die Rechnung (ohne den Bauplan) mitnichten einfach 
ist, sondern enorm aufwendig und komplex.  (Und das es deshalb sinnvoll 
wäre, wenn man den Bauplan / die Struktur fürs Grobe hätte.)


> die Beziehungen ergeben sich aus den tags (admin_level) in Kombination
> mit der räumlichen Konfiguration.

Das ist nur zum Teil richtig.  Die Beziehungen ergeben sich schon 
daraus, dass eine Flächengrenze für jedes admin_level wiederverwendet 
wird, wenn da mehrere drüber laufen.  admin_level ist eigentlich eine 
redundante Information - die Bundesgrenze z.B. wäre genauso gut dadurch 
ermittelbar, dass ihre Flächengrenzen X-fach wiederverwendet werden 
(wobei Bundeslandgrenzen im inneren nur (X-1)-fach wiederverwendet 
werden, usw.)

admin_level ist genau das, was Du sonst ablehnst:  Etwas, dass man 
"einfach" errechnen könnte.


Gruß
Christian




Mehr Informationen über die Mailingliste Talk-de