[Talk-de] landuse übereinander

Tordanik osm at tobias-knerr.de
So Okt 5 09:14:58 UTC 2008


Markus schrieb:
> Für mich als Laie sieht das ganz einfach aus:
> die kleinere Fläche /überdeckt/ die Grössere.
> […]
> Dadurch könnte man sich doch die ganzen Konstrukte mit inner/outer und 
> +1/-1 ersparen? Das würde die OSM-Struktur für alle einfacher machen: 
> für Datensammler, für Renderer, für Anwendungsprogrammierer?

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. Natürlich gibt es andererseits aber auch
echte Löcher in landuses, so dass man ohne Hilfe des menschlichen
Bearbeiters wohl kaum eine zuverlässige Entscheidung treffen kann.

Auch ohne diese Erwägung könnte man sich die beiden genannten Konstrukte
wohl sich nicht ersparen. Layer braucht man immer noch für (zumindest
manche) Brückenkonstruktionen o.ä. – dafür sind sie nämlich eigentlich
da, nicht für Landuse-Render-Hacks –, Multipolygon zumindest für den
Fall, dass man ein Loch in einem Objekt hat, das selbst keine
Information trägt.

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.

Datensammler, die mit den komplexeren Fällen in Berührung kommen, müssen
ebenfalls alle drei Techniken kennen, sie sparen sich natürlich ein
wenig Tipp- und Klickarbeit bei den einfachen Fällen. Diejenigen, die
wirklich profitieren könnten, sind Datensammler, die nur einfachere
Informationen einbauen (also nicht mit komplexeren Fällen in Berührung
kommen) und sich auch nicht mit der Struktur der von ihnen erzeugten
Daten auseinandersetzen wollen.

So etwas wäre aber m.E. wegen der zusätzlichen Lasten für Anwendungen
sowieso nicht im Datenmodell richtig aufgehoben, sondern in den
Editoren. Die können gerne die Fähigkeit haben, etwa automatisch
Mulipolygon-Relationen zu erzeugen, wenn du oder jemand anderes das
ergonomisch hinbekommst. Das verschiebt den Aufwand von Anwendungen auf
Editoren, was angesichts dessen wünschenswert ist, dass hoffentlich weit
mehr Anwendungen als Editoren geschrieben werden – ansonsten machen wir
irgendwas falsch. ;-)

Tordanik




Mehr Informationen über die Mailingliste Talk-de