Am 19.09.2011 20:16, schrieb Martin Koppenhoefer:
Am 19. September 2011 19:34 schrieb Christian Müller<cmu...@gmx.de>:
Am 16.09.2011 11:16, schrieb Martin Koppenhoefer:
Du täuschst Dich hier. Siedlungsstellen lassen sich nicht automatisch
errechnen, weil die Informationen dazu fehlen. Bei den landuses - so
man sie alle erfasst hat - sind die benötigten Informationen hingegen
vorhanden. Daher geht es da.
-1 Das ist, sorry, absoluter Unfug.
/Erstens/ sind die benötigten Informationen für die Siedlungsstellen
existent, wenn landuses komplett erfasst sind.
Du willst es nicht verstehen. Es ist nicht klar, zu _welcher_
menschlichen Siedlung sie gehören. Das ist das Problem, nicht, ob sie
besiedelt sind.
Natürlich ist das klar - anhand der Gemeinde, bzw. Gemarkungsgrenze,
innerhalb derer die landuses liegen. Im allgemeinen umfassen politische
Grenzen einer Gemeinde einen größeren Bereich, mindestens aber den
Bereich der Siedlung.
Selbst wenn eine politische Grenze aktuell nicht mehr zu finden ist,
wird es eine historische geben, die für die Ermittlung benutzt werden kann.
Die Information einer Siedlungsflächengrenze ist damit klar redundant
[[denn es gibt Regeln, mittels derer sie sich ausrechnen lässt]]. Ich
vertrete aber die Auffassung, dass diese Regeln nicht außerhalb der DB
stehen sollten.
Schließlich ist sie über eine Relation innerhalb OSM effizient pro Fall
abbildbar. In gewisser Weise steckt Redundanz dann nur dadurch in der
DB, dass die Regel mehrmals angewandt wird. Das hat aber eben auch den
Vorteil, dass Ausnahmen ohne weiteres abbildbar sind.
Bisher standen dazu in unserer Debatte zwei Realisierungen zur Auswahl:
a) Erfassung über (wiederbenutzte) Flächengrenzen b) Erfassung über
Sammelrelation aller Teilflächen der Siedlungsfläche. b) hat klare
Nachteile gegenüber a), siehe Datenhaltungsmail.
Das ist alles nur Wiederholung, siehe frühere mails..
/Zweitens/, kannst Du aus einem Netz MICROgemappter Flächen _nicht_ oder nur
mit sehr hohem Aufwand (sprich komplexe, regelbasierte Algorithmen) sinnvoll
auf ein Netz grobgranularer Flächen schließen.
So kompliziert ist das nicht.
Du lehnst Dich hier viel zu weit aus dem Fenster. /Wie/ kompliziert das
werden kann, überblickst Du gar nicht. Ich überblicke das auch nicht,
behaupte aber auch nicht, dass ich das könnte.
Der immense Vorteil ist aber dabei, dass
alle Informationen vorliegen und ich selbst entscheide, was für mich
unwesentlich ist, und was nicht.
Ich lese nur /ich/ in deinen Sätzen. So funktioniert OSM nicht. Um
/als Datennutzer/ entscheiden zu können, was für mich wesentlich ist,
muss ich aus einem Angebot /wählen/ können. /Du/ bist hier gerade
derjenige der einem dieses Angebot vorschreiben will, weil /Du/ der
Meinung bist, dass ein Salat aus MICROgemappten Flächen ausreiche, um
sich alle erdenklichen gröberen Fälle auszurechnen.
Umgekehrt muss ich /als Mapper/ /wählen/ können, auf welcher Ebene ich
Informationen zum Projekt hinzufüge. Nicht jeder hat die Muse, deinen
Vorstellungen von Größen, die "nicht weiter teilbar" sind,
nachzukommen. Solche Leute dürfen dann keine Flächennutzung mehr
erfassen, oder wie? Und der nächste MICROmapper, der kommt, und das
Gebiet der Forstwirtschaft dann "parzelliert" zerstört die Arbeit des
MACROmappers - weil eben das Gebiet der Forstwirtschaft _nicht_
notwendigerweise, wie Du schreibst, aus Mini-Parzellen zusammensetzbar ist.
Ich bin der Meinung, dass Du immer noch nicht durchdacht hast, welche
wirklichen Konsequenzen deine Streichung von "überwiegend" aus der
Definition zur Flächennutzung hat. Nochmal, wenn Du die "reine" statt
überwiegende Flächennutzung erfasst, heißt das für Dich und alle, die Du
damit begeistern willst:
a) Erfassung aller erdenklichen Flächennutzungen einer Fläche
b) Unterteilung der vorhandenen Fläche in kleinste Einheiten, die
eine __eindeutige__ Erfassung der Flächennutzung ermöglichen
Ich bitte Dich nochmals, mitzudenken: Eine Fläche beliebiger Größe kann
_immer_ nochmal geteilt werden, um die Flächennutzung genauer zu
erfassen: Selbst für einen Acker funktioniert das: linienschmale
Flächen werden z.B. als Furche des Ackers genutzt.
Bist Du allen Ernstes der Aufassung, dass aus diesen kleinsten,
MICROgemappten landuses, sich _jeder_ diese gröberen Gebiete aus einem
komplexen Regelset "zusammenbauen" will? Die Regel für den Acker wäre dann:
Gruppiere alle Furchen, um das Gebiet des Ackers zu erhalten.
(Total einfach! Da braucht man doch die überweigende Nutzung der
Gesamtfläche als Acker gar nicht erfassen..)
Ganze Softwareprojekte würden sich dann damit beschäftigen, Regelwerke
zu pflegen, weil /Du/ der Auffassung warst, dass die Gruppierung
feingranularer Strukturen in "gröbere" ja ein Kinderspiel sei (es aber
schon für die Berechnung der Siedlungsflächengrenze verneinst!).
Es geht nämlich nicht nur um die
Flächengröße sondern auch um die Art der Nutzung. Eine kleine aber
extreme Nutzung ist für bestimmte Fragestellungen interessant. Wenn
man alles vermanscht, fehlen die Infos nachher.
Gerade ein Flächennetzwerk erlaubt, was jetzt nicht möglich ist:
Extreme Nutzungsänderungen für kleine Gebiete zu erfassen, ohne dabei
das gröbere Gebiet zu zerstören. /Ob/ die extreme Nutzungsänderung
interessiert oder nicht, bestimmt
bei der Erfassung: der/die MapperIn
bei der Nutzung: der Datennutzer
und nicht /eine/ /einzige/ Person. Momentan gibt es kein
Flächennetzwerk der Bodennutzung und wenn es existiert, dann an lokalen
Stellen, wo Mapper das Problem erkannt, aber dessen Lösung nicht
publiziert haben (Wiki, Mailingliste). Das bedeutet:
MICROmapper X kommt, mappt die grob erfasste Bodennutzung von
MACROmapper Y neu und die (sinnvolle!) Gruppierungsinformation ist
verloren. Y kann sich ja sein Zeug, aus den neuen Flächen schon
irgendwie errechnen --> Super Einstellung, so macht zusammenleben und
-mappen Spaß..
Dann sollten wir das aber auch für die Siedlungsfläche so handhaben.
Schließlich kann sich auch Mapper Martin aus den MICRO-landuses
innerhalb irgendeiner politischen Grenze den landuse=settlement
zusammenrechnen.. Oder wollen wir für manche gröbere landuses ein paar
Ausnahmen schaffen?
Das ist alles vergebene Liebesmüh, denn wir haben schon festgestellt:
Der Mapper bestimmt, /was/ /wie/ gemappt wird.
Der Nutzer bestimmt, /was/ er davon haben will.
Ohne irgendwelche Verbote, kann OSM elegant beides bedienen, indem
einfach der Fakt anerkannt wird, dass auch bei der "überwiegenden realen
Bodennutzung" Beziehungen zwischen den Einzelflächen bestehen und sich
Bodennutzungsflächen durchaus überlappen können. Die Erfassung der
Bodennutzung muss nicht disjunkt erfolgen, das wäre eine Forderung nach
_unmöglicher_ Pedanterie.
Beispiele: Ein Gebiet wird überwiegend für das Wohnen verwendet, wir
erfassen es als landuse=residential. Außerdem gibt es eine kleine
Stelle innerhalb des Wohngebietes, wo die Flächennutzung "extrem" (was
extrem ist, ist auch Ansichtssache) schwankt, wir erfassen also
landuse=residential.
Was bedeutet das? Ich habe eine Information, mit der ich ein großes
Gebiet klassifizieren kann "_überwiegend zum wohnen verwendet_". Wenn
mich nur dieses Gebiet interessiert, interessiert es mich nicht, ob und
wieviele extreme Nutzungsänderungen innerhalb winziger Teilflächen
dieses Gebietes stattfinden. Gleichfalls muss ich den Fakt anerkennen,
dass sich andere evtl. für eine detailierte Flächennutzungsaufteilung
interessieren. Gleichfalls müssen die, welche die detailierte
Flächennutzungsaufteilung interessiert, anerkennen, dass es Leute gibt,
die sich für gröbere Strukturen interessieren, für die es also
vernachlässigbar ist, dass es extreme Nutzungsänderungen innerhalb eines
Gebietes gibt.
OSM kann beide Welten problemlos verbinden, indem Flächengrenzen als
/way/ und Flächen als /multipolygon/ erfasst werden. Dann lassen sich
Flächen beliebiger Strukturgröße nach bestem Wissen und Gewissen durch
Mapper bilden, ohne dass ein Mapper einem anderen Mapper /seine/
Vorstellung von "einer" "wahren" Flächengröße aufdrücken muss. Es gibt
nicht die "wahre" Flächen, bzw. Strukturgröße, auf der Daten erfasst
werden, sondern ein Spektrum, dass von der Größe eines Kontinents bis
zur Größe eines Wegweisers reicht.
Solange Du behauptest, dass man "nur" Bodennutzungen MICROmappen müsste,
um alle glücklich zu werden, verschiebst Du die Diskussion, die wir
/hier/ führen, einfach nur in einen /anderen/ Größenbereich, um sie dort
zu wiederholen.
==> Eventuell triffst Du dort dann NANOmapper, der Dir erklärt, dass es
Unfug ist, landuse=* MICRO zu mappen, weil MICROgemappte landuses ja
ohne Probleme aus NANOgemappten errechenbar seien..
Natürlich kann ich nur politische Gemeindegrenzen innerhalb der DB pflegen
und dann extern die Bundesgrenze ausrechnen. Das machen wir aber eben
nicht, weil die Vorteile einer expliziten Erfassung innerhalb der DB (mit
Bezügen der Grenzen untereinander) klar überwiegen!
+1
daher sind Siedlungen auch besser nicht die Summe verschiedener
Landuses sondern ein extra Polygon.
Genau hier musst Du weiterdenken.. Das ist nicht die ganze Wahrheit,
denn die _gleiche_ Argumentationsweise, die Du verwendest, um Dich gegen
die automatische Errechenbarkeit einer Siedlungsflächengrenze zu wehren,
zählt auch, wenn ich behaupte, dass der landuse=* eines
Forstwirtschaftsgebiet aus seinen MICRO oder NANOgemappten Teilnutzungen
_nicht_ errechenbar ist, sondern über "ein extra Polygon" (multipolygon)
erfasst werden soll.
Egal ob das gröbere Gebiet nun eine Siedlung darstellt, oder ein
Forstwirtschaftsgebiet - weshalb sollten gröbere Gebiete jedes Mal, wenn
ein Nutzer sie braucht, berechnet werden?
Wenn ich weiß, welche Wege zu einer Radroute gehören, kann ich mir das
auch jedes Mal aus OSM-Daten ausrechnen. Das brauche ich aber nicht,
denn das Ergebnis dieser Rechnung ist Teil der Realität und damit Teil
von OSM (vorgehalten durch eine type=route Relation).
Falls man das Argument der Errechenbarkeit zu Ende denkt, kommt man
darauf, dass es eigentlich reicht, nur die nodes zu erfassen. Alles
andere lässt sich doch, entsprechendes externes Wissen vorrausgesetzt,
auch extern ausrechnen..
Betrachte bitte die Relationen in OSM. Beziehungen zwischen den Daten sind
nicht immanent und einfach so da!
doch, die Lage ist einfach so da, genauso wie die Größe einer Fläche,
oder was innerhalb und ausserhalb einer Fläche liegt, bzw. welche
Flächen sich schneiden. Da musst Du z.B. nicht noch die Flächengröße
dazuschreiben, auch wenn manche das trotzdem machen.
Ja, was denkst Du wohl, weshalb einige die Flächengröße dranschreiben?
Weil die Ermittlung des Ergebnisses wesentlich aufwendiger sein kann,
als einfach diesen Wert nachzuschlagen.
Die Lagebeziehung zwischen zwei Flächen ist _nicht_ einfach so da! DU,
als Mensch, kannst zwei Polygone zeichnen und dann sagen, das eine liegt
innerhalb des anderen oder meinetwegen auch, die beiden Polygone
schneiden sich. Das kannst DU, als Mensch, recht schnell für kleinere
Polygone tun, aber auch nur dann, wenn Du eine visuelle Darstellung der
beiden Polygone vor Dir hast.
Für eine Maschine ist die Lagebeziehung der beiden Polygone solange
nicht gegeben, wie Du sie nicht explizit angibst (in Bezug setzt, eine
Relation erstellst) __oder__ durch ihre Koordinaten errechnest. Das
kann, in Abhängigkeit der Menge der Polygone, die in Bezug zu setzen
sind, und ihrer einzelnen Größen sehr schnell sehr aufwendig werden.
Deine Aussage, dass irgend zwei "closed ways" automatisch eine immanente
Beziehung zueinander in der DB hätten, ist also schlichtweg falsch. Die
Beziehung ist nicht immanent, sonder maximal "ermittelbar".
Beziehungen zwischen Objekten innerhalb einer DB sind _nicht_ einfach so
da. Sie müssen definiert werden (entweder durch Algorithmen, die
Bezüge ermitteln, oder durch Datenstrukturen, die Bezüge
speichern/vorhalten).
Immanent in der DB sind grundsätzlich ersteinmal nur die Beziehungen
zwischen
node - lat,lon pair
way - node list
relation - way or node
relation - relation
Eventuell noch, aber da wird es schon wackelig: closed way - area
Eine echte area (Flächentyp) kennt die DB überhaupt nicht! Wie willst
Du da behaupten, dass Flächenbeziehungen untereinander immanent wären?
Einem multipolygon z.B. sind die Beziehungen zwischen seinen
innliegenden Polygonen und dem außenliegenden Polygon "immanent". Das
ist aber gerade, wovon ich rede: Generell Flächen als multipolygon zu
erfassen, weil damit (einige) Flächenbeziehungen immanent gegeben
wären. Das ist bis jetzt keine durchgängig angewandte Praxis (von
politischen Grenzen, auf die Du dich _nicht_ beschränkt hast, einmal
abgesehen).
Was aber nicht passieren darf (!), ist, dass sich unter den Render-Regeln,
Regeln befinden, wie Daten der Realität gruppiert werden, die schon in der
Realität gruppiert werden.
Die Renderregeln leisten das: Daten selektieren und ggf. gruppieren.
Der letzte Teilsatz war wichtig - ich schrieb ihn nicht zum Spaß. ",
die schon in der Realität gruppiert werden."
Das schließt eine ganze Menge an Renderregeln aus.
/Falls/ Renderregeln Daten der Realität auf eine Art und Weise
gruppieren, so dass die Selektion, die der Renderer da tätigt, einer
Selektion/Gruppierung gleicht, die bereits Teil der Realität ist, dann
hat diese Gruppierungsregel _nichts_ in den Renderregeln verloren.
Das Ergebnis der Gruppe sollte _dann_ stattdessen als Relation innerhalb
der OSM-DB existieren. Idealerweise sind Renderregeln reine
Layout-Regeln, es wird also nur des Layouts wegen gruppiert und nicht,
wenn Daten schon in der Realität gruppiert (lies: in Beziehung gesetzt)
werden. Letzteres ist Teil von OSM. Beispiel:
Es gibt mehrere Buslinien innerhalb eines Netzwerks.
Der Renderer gruppiert sich diese Buslinien anhand des
network-Tags, um dann einen Stil zu definieren.
Diese Gruppierung gibt es aber schon in der Realität, es wäre also
besser, das Netzwerk in OSM abzubilden:
Relation type=network ... mit den Buslinien als Mitglieder.
.. und als Renderregel den Stil für das network festzulegen.
Als Richtlinie kann man sich evtl. merken: Solange eine Renderregel
/selektiert/, ist alles in Ordnung. Sobald eine Renderregel
/gruppiert/, muss man sich als Layouter die Frage stellen, ob die
Gruppierung _wirklich nur_ für Layoutzwecke stattfindet, _oder_ nicht
evtl. ein Workaround um eine fehlende Relation in OSM ist.
folgendes:
- ein Renderer gruppiert sich die Elbe-Radroute aus den Wegen der DB auf
die eine Art
- der nächste auf eine leicht andere Art
sorry, aber irgendwo haben Vergleiche auch ein Ende, und ein linearer
Radweg ist schlecht mit dem Problem hier vergleichbar.
Ich seh' schon - Du bist jemand, der nicht zwischen Radweg und Radroute
unterscheidet. Dann trifft der Vergleich natürlich auch nicht ins Schwarze.
Und nein, Vergleiche müssen nicht /irgendwo/ ein Ende haben, sondern
dort, wo sie nicht mehr zutreffen.
Eine Radroute aus /ways/ in den Rollen 'Teilabschnitt' zu bilden.
ist vergleichbar mit
Eine Fläche aus /ways/ in den Rollen 'Flächengrenze' zu bilden.
Wenn die Radroute ein Rundkurs ist, werden beide Sachverhalte sogar auf
identische Weise abgebildet:
Die Relation enthält dann in beiden Fällen
aneinandergeschlossene Wegsegmente.
Es nehmen nur solche Wegsegmente Teil, deren Endpunkte auch
Anfangspunkte eines anderen teilnehmenden Wegsegmentes sind.
Ob das ganze als Route oder Fläche interpretiert wird, entscheiden
dann nur noch die Relations-Tags..
"richtig" im Sinne der Frage, ob die entstehende Gruppierung eine Abbildung
der Realität ist [...]
wie Frederik schon treffend sagte: um richtig und falsch geht es
nicht, in jedem Fall machen wir hier ein Modell der Welt, das man
nicht mit der Welt verwechseln sollte.
+1 "richtig im Sinne der Frage, ob [...] eine Abbildung der Realität ist"
"richtig" beschäftigt sich mit der Realitätstreue des Modells.. Ist die
Abbildung gut oder wird unzulässig abstrahiert, etc.
Wenn ein Sachverhalt im Bezug auf das Modell "falsch" ist, aber in der
Realität existent, stellt sich die Frage, inwieweit das Modell angepasst
werden muss...
M.E. geht es in der Diskussion
hier darum, herauszufinden, wie unser Modell am besten abbilden
sollte, dass:
- es Verwaltungseinheiten und dazugehörige Verwaltungsgrenzen gibt,
- es davon unabhängig Siedlungen und Teile davon gibt,
- dass jedes Stück Land irgendwie genutzt wird, oder eben nicht
+1 Wenn Du aber dogmenartig am "Modell" hängst, wird daraus Mist.
Du musst nicht nur herausfinden, wie die Realität in das Modell passt.
Du musst auch prüfen, ob das Modell überhaupt geeignet ist, deine
genannten Aspekte der Realität zu erfassen. Das ist eine Arbeit von
zwei Seiten. OSM nutzt ein evolutionäres Datenmodell, sprich, ein
Datenmodell, das sich fortentwickelt. Es ist keine Vorschrift des
Projektes, dass der _jetzige_ Stand des Datenmodells für immer und ewig
aktueller Stand bleibt.
Es gibt viele Stellen, an denen sich das Datenmodell bewiesen hat (true
and tested). An denen ist es schwer Argumente für eine Änderung zu
finden, weil die Argumente ja aufzeigen müssten, wie etwas, dass sich
bewiesen hat, noch besser geht. Es gibt aber auch (nicht wenige)
Stellen, an denen es einfach nur Mist ist, weil Struktur fehlt, weil
Dinge vermischt werden, die in der Realität ausdifferenzierbar sind, etc.
OSM kann die Realität nicht abbilden, ohne zu strukturieren. Es ist ein
klares Strukturierungsprojekt. Mischmasch, Brei und Chaos sind auch
Teile der Realität, die werden in OSM durch die Änderungsrate eines
Gebietes abgebildet: Ein Mapper, der mit der bestehenden
Ausdifferenzierung eines Gebietes nicht zufrieden ist, "strukturiert das
Gebiet um". I.d.R. erhöht er dabei Genauigkeits-, Detail- und
Strukturierungsgrad. Die Änderungsrate eines Gebietes erfasst in OSM
auch jenes Chaos der Realität, welches durch permanente
Gebietsumgestaltungen des Raumes (etwa in Städten) entsteht.
weiterhin wären noch jede Menge andere Betrachtungsweisen denkbar
(aber nicht alle sinnvoll in OSM aufgehoben), z.B. die Bodenbedeckung,
die Vegetation, der Feuchtigkeitsgehalt des Bodens, das Klima, der
geologische Untergrund, die Bebauungstypologie, die Einwohnerdichte
+1 genau. OSM lässt sich für diese Anwendungsfelder öffnen. Das ist
aber m.E. erst dann sinnvoll, wenn die Grundlage stimmt:
Bessere Unterstützung für Flächenerfassung in Editoren
Multipolygone für die Zusammenarbeit von Makro-, Micro- und
Nanomappern (Flächennetzwerk..)
Dokumentation und schlüssige Definition im Wiki, wie Tags
Verwendung finden
=Zukunftsmusik===========
Damit kann dann auch eine echte Zusammenarbeit zwischen Laie und
Spezialist klappen, ohne dass sich beide gegenseitig die Arbeit
zerstören, oder ein Disput enststeht, wo eine Fläche erfasst werden
"darf" und wo nicht. Die Chancen sind groß, dass damit auch die
bestehende Datenqualität erhöht wird und OSM zu dem Wiki ortsbezogener
Information wird.
Es ist dann z.B. auch echt diskutierbar, /welche/ Flächengrenzen
zusammenfallen und welche nicht. Man unterhält sich dann also nicht
mehr über die Datenhaltung, ob Flächen zusammengepappt werden dürfen,
oder an Wege geklebt, oder sonstwas, sondern um echte fachliche Fragen -
welche Spezialgebiete brauchen ein eigenes Flächennetzwerk, welche
können sich eins mit anderen Spezialgebieten teilen. Welche Beziehungen
gibt es zwischen diesen entstehenden Flächennetzwerken, etc. Auf diesem
Wege kann OSM helfen Zusammenhänge zu entdecken, die bisher nicht
entdeckt werden, weil die Datenbasen von Spezialisten getrennt
voneinander gepflegt werden.
=Ende Zukunftsmusik===========
Momentan würde ich mich auf den Bodennutzungsaspekt beschränken. Wenn
es dafür nicht gelingt, alle Ansprüche unter einen Hut zu bringen,
braucht man nicht weiter träumen. Ohne irgendeinen Bezug (und damit die
Möglichkeit der Zusammenarbeit untereinander) zwischen Flächen wird es
nicht gehen. Wenn wir da weiter mit "closed ways", "overlapping ways",
geklebten ways, dicht nebeneinanderliegenden doppelten ways, etc.
rummanschen und jeder sein eigenes Süppchen kocht, bleiben
Sinnzusammenhänge der Daten für/in OSM verborgen. Diese dann
herzustellen, bleibt individuelle Aufgabe für clevere
Algorithmenschreiber, die aus dem Rausch-Salat ein bisschen Signal
herausholen.
Ich komme nochmal auf die Radrouten-Analogie zurück:
Aus dem Schatz _aller_ Wege innerhalb OSM (abzüglich derer, wo das
Radfahren verboten ist), können Wege ausgewählt werden, um eine Route zu
bilden. (Route - Relation mit type=route)
Die Analogie für Flächen dazu: Aus dem Schatz _aller_ Wege innerhalb
OSM, können die Wege ausgewählt werden, die eine Fläche begrenzen.
(Multipolygon - Relation mit type=multipolygon)
Späten Gruß
Christian
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
