[Talk-de] 3D Features von Gebäuden, weclhes Schema?

Martin Koppenhoefer dieterdreist at gmail.com
Fr Sep 7 12:15:27 UTC 2012


Am 7. September 2012 13:32 schrieb Peter Wendorff <wendorff at uni-paderborn.de>:
> Am 07.09.2012 12:14, schrieb Martin Koppenhöfer:
>> Was ich an dem Schema seltsam finde, ist die Definition von
>> http://wiki.openstreetmap.org/wiki/Key:building:levels
>>
>> Damit wird laut Schema im Fall von Brückengebäuden und kragenden Bauteilen
>> nicht die Anzahl der Stockwerke die das Gebäude hat beschrieben, sondern die
>> Anzahl, die es bei durchschnittlicher Stockwerks-Höhe hätte. D.h. Ein
>> zweigeschossiges Bauteil wird z.b. Mit 7 getaggt, wenn es sich in entspr.
>> Höhe befindet.
> Eine Anwendung, die diese "Brücken" nicht unterstützt, kann weder mit der
> einen noch mit der anderen Variante was anfangen.


stimmt so nicht ganz. Eine Anwendung die diese Brücken nicht
unterstützt könnte, solange building_levels die Stockwerksanzahl
angibt, z.B. trotzdem die Bruttogeschossfläche berechnen (Grundfläche
x Stockwerksanzahl), oder (falls die durchschnittliche Höhe gegeben
ist) auch das Bruttovolumen (dafür braucht sie nicht zu wissen, ob
dieses Volumen auf dem Boden liegt oder in der Höhe hängt). Beides
sind sehr wichtige Parameter wenn es darum geht, die Bebauungsdichte
eines Gebiets zu beurteilen.


> Für Rendering-Software sieht aber eine Brücke, der der Tunnel fehlt, besser
> aus als eine Brücke, die runtergefallen ist, so dass aus einem n ein u wird
> (bildlich gesprochen).


Geschmackssache, beides m.E. derart unschön, dass man sich wohl kaum
damit abfinden wollte. Wir taggen aber nicht (nur) für Renderer.


> Unser Ergebnis damals war, dass das fallback durch die Nicht-unterstützung
> der Besonderheiten, die sich durch Überhänge und Brücken ergeben, besser
> ist, wenn levels quasi das höchste (überirdische) stockwerk angibt statt der
> anzahl tatsächlich existenter Stockwerke.


ja, leider. M.E. sollten wir uns das nochmal überlegen, ist logisch
inkonsistent und erschwert unnötig das Verständnis der Daten (man ist
zwangsläufig auf Dokumentation angewiesen, sonst sind
Fehlinterpretationen m.E. vorprogrammiert). Ich plädiere dafür, hier
so vorzugehen, wie es allgemein etablierte Praxis ist (z.B. in der
Architektur, im Städtebau, bei der Stadt- und Raumplanung, etc.), und
wie es auch sonst die tagging-Praxis in OSM ist (ein tag sollte
möglichst alleine auswertbar sein, und nicht andere Tags benötigen).
Einen zweigeschossigen Bauteil mit building:levels=7 zu taggen, weil
er eine Brücke ist, finde ich extrem fehleranfällig.

Nochmal kurz zusammengefasst: building:levels sollte m.E. die
Gesamtanzahl der Stockwerke angeben.

Gruß Martin




Mehr Informationen über die Mailingliste Talk-de