[Talk-de] Gebäude-Mapping

[Peter Wendorff]

Am 08.11.2010 12:30, schrieb M∡rtin Koppenhoefer:
> Am 8. November 2010 11:25 schrieb Peter Wendorff<wendorff at uni-paderborn.de>:
>>> Abgesehen davon überlege ich noch, wie ein Rendering am besten umgesetzt
>>> würde - speziell in dem Fall, wenn nicht für alle Gebäudeteile absolute
>>> height/min_height-Werte vorhanden sind.
>>> Ein Stockwerk ist ja nicht bei jedem Gebäude gleich hoch, und
>>> insbesondere auch nicht auf derselben absoluten Höhe. Also müsste ein
>>> Renderer wohl so vorgehen:
>>> * in einem ersten Schritt Gruppen von sich (ggf. transitiv)
>>> überlappenden Gebäudeteilen bestimmen
>>> * innerhalb jeder Gruppe absolute Höhen der Stockwerksgrenzen festlegen
>>> * mit dieser Information dann die Grundflächen der Gebäudeteile zwischen
>>> den jeweiligen Stockwerksgrenzen extrudieren
>>> Wäre eine solche Auswertung das, was du dir vorgestellt hast, oder
>>> hättest du eine andere - ggf. sogar einfachere - Idee?
>> Jein.
>> Ich würde einen einfacheren Ansatz vorziehen, der meist zu einem Ergebnis
>> führen dürfte und zusätzlich unnötige Fehler behebt:
>> Dabei fällt dein erster Schritt weg:
>> * Stockwerkhöhe wird, wenn nicht anders angegeben, konstant angenommen. Es
>> lässt sich also aus den Stockwerkangaben eine meter-Angabe berechnen, die
>> für nicht gesetzte Meterangaben herangezogen wird.
> in der Architektur nimmt man i.d.R. für vereinfachende
> Städtebaumodelle meist 2 Höhen an, grob vereinfacht für "Neubauten"
> (ca. ab 50er Jahre) 3 m und für Altbauten (davor) ca. 4 m. Das reicht
> für grobe Modelle schon aus. Wenn man die Gebäudetypen hat kann man
> noch weitergehende Annahmen treffen. Das Erdgeschoss ist oft etwas
> höher (generalisiert ca. 5m), insb. wenn es eine vom Rest abweichende
> Nutzung hat. Dazu kommt je nach Dach ggf. nochmal eine Attika oder ein
> sonstiger oberer Abschluss (Dachbühne, etc.), je nach Typ und
> Dachneigung 1m bis 5-8 m.
>
> Diese Höhen sind Geschosshöhen, also Deckenkonstruktion + Raumhöhe.
Für Architektur nicht schlecht und sicher auch hier machbar.
Dachkonstruktionen hab ich allerdings bewusst hier nicht beachtet, da 
mein Ziel ein anderes ist.

Mir geht es nicht in erster Linie um eine korrekte 3D-Darstellung des 
Gebäudes - die gehört tatsächlich in externe Modelle und hat in OSM 
direkt nichts zu suchen: spätestens bei bestimmten Details sind die 
Daten sonst nicht mehr handhabbar.
Mir ging und geht es eher darum, auch 3dimensional gültige 
Navigationsgraphen erzeugen zu können und Geschäfte etc. auch innerhalb 
eines Gebäudes korrekt zuordnen zu können.
>> Dabei entstehende Fehler lassen sich jeweils durch die Angabe der einzelnen
>> Höhen beheben.
> genau, ist aber schon aufwendiger: man braucht bei simplen geneigten
> Dächern (Satteldach, Pultdach, etc.) eigentlich vereinfacht nur 3
> Höhen: Erdboden, Firsthöhe und Traufhöhe. Dazuhin sollte man wissen,
> wie die Ausrichtung des Daches ist. Bei assymetrischen Dächern ist
> auch die Neigung (oder die Lage des Firstes) erforderlich (ergibt sich
> sonst automatisch). Komplexere Dächer sind nochmal ein Thema für sich.
Für die einfachen Fälle (aber über Flachdach hinaus) gibt es auch hier 
bereits proposals [1].
> Die o.g. Vorgehensweise geht für viele Gebäude ganz gut, aber nur für
> die "langweiligen", sobald Du Splitlevel oder gar geneigte
> Bodenflächen (Rampen etc.) hast, wird es komplexer.
Das ist richtig.
Für eine genaue Beschreibung geht IMHO nichts an externen 3D-Modellen 
vorbei.
>> Ein größeres Problem, zu dem mir tatsächlich noch keine Lösung einfällt,
>> besteht bei Gebäuden am Hang, bei denen das "Erdgeschoss" je nach Seite
>> unterschiedlich ist. Hier sehe ich aber auch keine Lösung, ohne Höhendaten
>> der Umgebung hinzuzufügen, die uns bisher vollständig fehlen.
> Das wäre auch nochmal ein Spezialfall, ja, aber sobald Du 2
> Erdgeschosshöhen zuordnest wäre dieser Fall geklärt.
Dafür müssten aber leider Attribute an TEILE von Polygonen gepappt 
werden, denn ein Attribut am Polygon kann nur sagen Erdgeschoss oder 
nicht-erdgeschoss. Zu beschreiben "Erdgeschoss auf den südlichen zwei 
Dritteln der Ostseite und dem östlichen viertel der Südseite" ist glaub 
ich nicht so ohne weiteres verwendbar möglich.
>   Denkbar sind ja
> auch Gebäude mit Tiefhof, G. in einer "künstlichen" Landschaft
> (Treppen, Podeste, Plattformen, Plätze, etc., alles Teil des Gebäudes
> bzw. drum rum, z.B. sowas hier:
> http://mw2.google.com/mw-panoramio/photos/medium/4731995.jpg
> http://www.roppongihills.com/common/img/en/ph_sr_index_vi_01.jpg
Klar.
Aber hier bewegen wir uns auf die Notwendigkeit eines Höhenmodells zu; 
ein Thema, das bisher ausschließlich umgangen worden ist, soweit ich 
weiß: Höhenlinien werden für einige Karten importiert, aber immer aus 
externen Quellen und ohne Auswirkungen auf das restliche Rendering.

Ich hielte es auch für keine gute Idee, Höhenlinien vermischt mit den 
restlichen Daten zu taggen;
hier könnte man aber hervorragend einen tatsächlich dedizierten 
zusätzlichen Layer in der API einführen, der von Editoren etc. auch 
ausgewertet werden könnte. (das ist aber ein großes Fass, das ich 
persönlich gar nicht austrinken möchte - selbst wenn ich es hiermit 
aufgemacht haben sollte)

Gruß
Peter

[1] 
http://wiki.openstreetmap.org/wiki/Proposed_features/Building_attributes