Am 08.11.2010 12:30, schrieb M∡rtin Koppenhoefer:
Am 8. November 2010 11:25 schrieb Peter Wendorff<[email protected]>:
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
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
