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
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
