[Talk-de] landuse übereinander

Markus liste12A45q7 at gmx.de
So Okt 5 11:29:47 UTC 2008


Hallo Torsten,

>> die kleinere Fläche /überdeckt/ die Grössere.
> 
> Es gibt aber gerade bei landuse oft den Fall, dass eine kleinere Fläche
> das landuse nicht ersetzt, sondern ergänzt – ein Parkplatz ist kein Loch
> im Gewerbegebiet, sondern Teil davon. Gilt auch für viele andere Dinge,
> nicht zuletzt auch für Gebäude. 

Ja, dafür braucht man Regeln.
Damit die Datensammler wissen was sie zu den Elementen dazuschreiben 
sollen, und damit die Renderer und Statistiker etc. wissen, wie sie die 
Daten verstehen sollen.

Die von Dir beschriebene Problematik hat mehrere Themen:
1. innen/aussen räumlich
2. innen/aussen relational
3. oben/unten räumlich
4. oben/unten hierarchisch

Viele Probleme stammen aus der Verwechslung dieser Themen einerseits, 
und dem Versuch, die Anwendungsprogramme über die Daten zu "steuern" 
(also direkt in die DB und deren Struktur einzugreifen) andererseits:
Der Eine meint: "Parkplatz" und "Industriegebiet".
Der Andere meint: "Parkplatz als Bestandteil des Industriegebietes".
Der Dritte will, dass der Parkplatz gerendert wird, unabhängig davon ob 
er in einem Industriegebiet liegt oder nicht.
Ein Statistiker will "das Industriegebiet mit allem".
Ein anderer Statistiker "alle Parkplätze im Industriegebiet" oder "alle 
noch nicht bebauten/genutzten Flächen im Industriegebiet".

Und wenn nun jeder eigene "Regeln" erfindet, um die Daten so zu 
manipulieren, dass der jeweilige Output seinen Vorstellungen entspricht, 
dann entsteht Chaos.

Ich stelle mir das als Laie so vor:
- jedes Objekt wird als solches beschrieben.
- Relationen werden /automatisch/ durch Georeferenzen gebildet.

Beispiel:
- Objekt A: Parkplatz
- Objekt B: Grenze des Industriegebietes
- Relation 1: alle Parkplätze
- Relation 2: alle Industriegebiete
- Relation 3: alle Parkplätze im Industriegebiet
- Relation 4: alle Restflächen ausser Parkplätze im Industriegebiet
Bei mehr Objekten im Industriegebiet, und/oder bei mehreren sich 
überschneidenden Gebieten wächst die Zahl der möglichen Relationen 
natürlich enorm. Es macht dann Sinn, nur solche als Relation 
vorzuhalten, die von Anwendungsprogrammen regelmässg gebraucht werden. 
alle anderen können bedarfssensitiv virtuell erstellt werden.

> Layer braucht man für komplexe Brückenkonstruktionen 

Zumindest solange das mit alt=# nicht funktioniert.

> Multipolygon für ein Loch in einem Objekt, 
> das selbst keine Information trägt.

Wieso?
Wenn das Attribut des "Loches" noch nicht bekannt ist, lässt man es 
einfach leer. Und meist weiss man ja auch, was sich im "Loch" befindet?

> Für Renderer- und Anwendungsprogrammierer bedeutet das: Die Regeln
> müssen trotzdem implementiert werden, nur eben die zusätzliche
> Einschlussprüfung auch noch. 3 Konstrukte statt 2 klingt nicht
> einfacher. Ich halte solche generellen „Liegt Polygon A in Polygon
> B“-Tests über alle potentiell in Frage kommenden Polygone auch (ohne es
> bisher programmiert zu haben) für weit aufwändiger als eine Relation,
> bei der ich die Teilnehmer bereits kenne, und daher weit weniger Objekte
> prüfen muss.

Wie gesagt:
Der Datensammler kommt damit gar nicht in Berührung.
Er schreibt: "das ist ein Parkplatz" oder "ein Industriegebiet".
Was wie wann in die DB kommt, macht ein Programm hinter dem Editor 
entsprechend transparenter Regeln.
Die Relationen werden über Georeferenzen erzeugt.

Nur besondere und nur duch Wissen um reale Gegebenheiten vor Ort 
entscheidbare Zusammenhänge werden zusätzlich per Klick gespeichert.

Beispiel Hausnummern:
Der Datensammler zeichnet die Strassen und die Häuser.
Dann klickt er eine Strasse und alle dazugehörigen Häuser an.
Das Programm erstellt dann die passende Relation
"Häuser an der Strasse (Strasse, Haus, Nummer)"

Alles andere wird durch georeferenzierte Bezüge abgebildet:
"ist innerhalb von" (Bayern, GemeindeXY, Industriegebiet, Wald, etc), 
die direkt der DB entnommen werden (oder für häufige Zugriffe zusätzlich 
in der DB gespeichert werden).

> Datensammler, die mit den komplexeren Fällen in Berührung kommen

Das sind nur wenige.
Die meisten schmeissen schon bei einfachen Fällen (Wald, Strasse, Weg) 
die Flinte ins Korn (oder schreiben halt "irgendwas" dazu).
Und ja, die Spezialisten für komplexe Brückenkonstruktionen müssen halt 
etwas mehr wissen als "der Rest der Welt", aber auch das ist nicht 
wirklich schwierig wenn die Regeln klar sind.

> Editoren können gerne die Fähigkeit haben, etwa automatisch
> Mulipolygon-Relationen zu erzeugen

Ja, die Editoren sind eine wichtige Benutzerschnittstelle!
JOSM leistet da schon sehr viel und ist schon sehr benutzerfreundlich.

Gruss, Markus




Mehr Informationen über die Mailingliste Talk-de