Workshop OSM 3D

Bitte bei dem 3D Modeller aber darauf achten, dass ich die Möglichkeiten habe von einer Etage in die nächste Verbindungen zu schaffen. Also Treppen und Rampen. Ebenfalls zu bedenken wären halbe Geschosse. Dies ist vor allem für Treppenhäuser interessant, aber möglicherweise auch für Gebäude aus unterschiedlichen Bauperioden, welche dann miteinader verbunden wurden wo es dann manchmal Treppen gibt.
Und nicht zuletzt sollten bei einer Uni auch Hörsääle und Kinos/Theater nicht vergessen werden. Diese beginne meist in einem Geschoss und gehen als Rampe mit Sitzreihen dann zur Bühne nach unten. Stadien haben das gleiche Problem.

Klar. Die Treppe muß von einem Geschoß in das andere. In 3D müßten Anfang und Ende entsprechend getaggt werden.
Zwischengeschoße sind problematisch, ebenso die versetzten Geschoße.
… enorm viel zu tun.

Hey erstmal langsam. Die Sachen sind verglichen mit dem “normalen” sehr selten. Sollten aber nur in dem Model möglich sein, da wir das ja nicht wieder umwerfen wollen. Wann es umgesetzt wird ist also erstmal woanders zu sehen.

Die gängige Lösung für solche Probleme (versetzte Geschoße) ist dass man die Hauptebenen definiert (Hapthalle, Hauptgebäude, Hauptteil von dem Gebäude) und für versetzte Geschoße entscheidet ob sie eher im Geschoß n, n+1 oder n-1 liegen.

Ja, aber für’s Rendern muss man ja doch angeben, dass das Stockwerk nun 1.5m oder so gegenüber den anderen versetzt ist.

Das ist absolut richtig, Errt!
Die Angabe der Höhen kann in den CAD Programmen, die üblicherweise mit einem Gebäude oder höchstens Gebäudekomplex zu tun haben durch die Definition einer Geschoßhöhe geschehen.
Für uns ist das unpraktisch weil die Höhen der Geschoße in einem Stadteil voneinander abweichen. Wir können also ein “Geschoß” nur als eine abstrakte Hilfe sehen, die zur Anzeige der Inhalte in einem Level gilt.

Dadurch müssen wir aber absolute Höhen der Stockwerke im Bezug auf relatives 0.00 angeben (Oberkante Fertigfußboden im Erdgeschoß).
Deswegen gibt es in OSM-4D Definition den Begriff "Decke.

Danke für die Erklärung. Dann sollte man nur noch für die hilfsweise Abbildung der Zwischengeschosse eine allgemeine Regel einführen, bspw. dass das nach oben versetzte Zwischengeschoss zu einem Geschoss dazugezählt wird. Oder was immer als Standard brauchbar ist. Wobei das natürlich die Gefahr birgt, dass derjenige, der die Räume im Gebäude nummeriert hat, das anders gesehen hat.

Hallo errt,
je mehr wir über die Angelegenheit diskutieren, umso mehr sehe ich dass ich es kaum allein schaffen kann, vernünftig zu dokumentieren, Beispiele zu zeichnen, Wiki anlegen.
Ich bin also allen die mitmachen und mitanpacken sehr dankbar!

Die Regelung für Zwischengeschoße könnte laufen: Liegt die Oberkante Fertigfußboden (OKFF) in weniger als dem halben Abstand zwischen der OKFF des darunter und darüber liegendem “Hauptgeschoß” wird sie zu dem GEschoß gezählt, wo der Abstand weniger ist.
Beispiel:
OKFF Erdgeschoß =0.50 m über Terrain, OKFF 1.OG= 3.50 über OKFF Erdgeschoß.
OKFF Zwischengeschoß = 1.25m über OKFF Erdgeschoß

In diesem Beispiel würde man die OKFF Zwischengeschoß dem Erdgeschoß zuordnen, da der Abstand kürzer…

Nachdem ich nun einigen Mailkontakt mit Tordanik habe bin ich leider etwas verwirrt, was das 3D tagging angeht. bei osm2world werden Roof:shape=* unterstützt, welche jedenfalls bei den einfachen Dachformen sehr ähnlich wie die entsprechenden 3dr Tags aussehen.
Was macht man nun also sinnvollerweise um nicht die Arbeit vergebens zu machen?
Auch scheint mir der Ansatz mit den Dachlinien bei komplizierten Gebäuden wesentlich intutiver zu sein, als hier komplizierte Dachformen zu errechnen. Das Problem des Startpunktes ist in osm2world ebenfalls bereits “gelöst”

Die Gebäude bei denen Dachlinien erforderlich sind, befinden sich in enger, unregelmäßiger Bebauung in engen Stadtzentren und sind die Minderheit, nicht desto trotz ist der Ansatz absolut richtig. Dieses Problem wird durch die Arbeit von Tordanik gelöst.
Für die Mehrheit der Gebäude ist die parametrische Beschreibungsweise wichtig weil:

  • Weniger Speicherbedarf
  • Bessere Generaliserungsmöglichkeiten für die Echtzeitdarstellung
  • Weniger Fehler bei der Modellierung.
  • zukünftig einfachere Texturierungsvorschriften.

Also BEIDES benutzen, denn BEIDE Ansätze werden in der “großen” Lösung berücksichtigt.

Kurzer Nachtrag:
Ich habe zwar unten auf der Roof Table Seite darüber geschrieben, aber ich erinnere es erneut:
die Bing bilder sink keine Orthofotos, deswegen haben die Dachlinien dort eine Parallaxe.
Die Parallaxe zu entfernen, bzw richtig zu interprätieren ist alles Ander als einfach, deswegen werden die 3D Modelle die auf dieser Grundlage gebaut sind, ziemlich besch…einden aussehen.

Beispiel Münchner Fraunkirche auf dem Bing Bild:

http://wiki.openstreetmap.org/w/images/4/48/MarekWhyIsPerspectiveDangerous.jpg

Man kann die Technik des Nachzeichnens verwenden wenn man nicht anders kann. Man sollte aber wissen welche Gefahr diese Technik mit sich bringt.

Braucht noch jemand Motivation für 3D?
http://wiki.openstreetmap.org/wiki/File:3D_Hauptstra%C3%9Fe.png

Klasse!
Gute Arbeit.

Grüße,
Marek

Wenn ich die Wandflächen mit den Fragezeichen so sehe: Hier ist es in Mode eine Seite eines Hauses mit tollen Sachen vollzumalen. Segelflieger oder kluge Sprüche von Dichtern: http://upload.wikimedia.org/wikipedia/commons/a/a7/Wurzen_Ringelnatzwand.JPG . Ist an sowas auch schon gedacht worden?

Hi Monotar,
ja: auch wenn dies zu früh ist ( keine Wiki, keine fertige spezifikation, in Sotware nicht ganz umgesetzt)
es sollen folgende Optionen gehen:

  1. Nix info → standardfarbe Wand und Dach in 3D Darstellung
  2. Nur Info Nutzung → Nutzungsabhängig definerte Farben für Wand und Dach

zusätzlich:
3. Anzahl Geschosse bekannt-> dazu leichte Farbabstufung der Geschoße, damit man die Anzahl der Geschoße erkennt.
zusätzlich:
4. Baustil angegeben->Baustil typische Textur (option rein spekulativ und nicht empfohlen, die Stile variieren zu sehr…)

  1. Texturen vorhanden ( aus fotos oder wie auch immer ) :
    5.1. Bei Roof table wid abhängig der Lage vom Punkt S die Reihenfolge der Texturen definiert, Die Texturen müssen mit einer Syntax gespeichert werden, was garantiert, dass sie an der richtigen Stelle abgelegt werden.
    Die Syntax wird resultieren aus der Nummer der Way und der Folgenummer der Textur.
    5.2. Bei OSM-4D sind wir noch beim diskutieren.

Gegenvorschläge sind gern wilkommen.
Grüße,
Marek

Nun es gibt auch noch http://wiki.openstreetmap.org/wiki/Proposed_features/advertising um Werbeflächen zu definieren. Da bräuchten wir nur ein Portal, wo man auch noch Texturen hochladen kann :wink:

Die einzige “Wand”-fläche mit einem Fragezeichen, die ich entdecken kann, ist der Baum, dessen Knoten nach meiner Sicht keine genaure Spezifikation über die Art und Größe besitzen dürfte. ( Also eher ein: Sorry, ich weiß es nicht besser!)

Auch der Hinweis auf das Propsal mit den Werbeflächen beinhaltet keinen Hinweis darauf, dass man die Beklebung oder Beflaggung genauer beschreibt (ich sehe schon die ersten Werbeagenturen Bugs schreiben, dass die Beklebung veraltet wäre). Dies wären wohl auch eher Inhalte, die außerhalb von OSM gespeichert werden sollten über ref:operator). Oder wollen wir lokale Werbekriege wie “Für Geschmack weiterfahren” zwischen Köln und der verbotenen Stadt (http://www.helbig-home.de/deg/haieak.html) auferstehen lassen (wenn möglich noch direkt in 4D :wink: )?

Der Ansatz ist gut, aber alles was über eine gewisse (männliche) Tiefe von Farbinformation (am weinroten Haus nach links abbiegen) hinausgeht, schießt für mich über das Ziel hinaus.

MfG Georg V. (OSM=user_5359)

Es haben alle Wandflächen und Dachflächen welche nicht rot oder weiß/grau sind Fragezeichen. Das rührt daher, das dort kein Materialtyp gesetzt ist. Bisher sind nur Farben und Dachziegel und Ziegelsteine definiert. Daher habe ich die anderen Flächen einfach undefiniert gelassen.Das ist das ganze Geheimnis.
Das Problem mit dem Baum ist auch nicht wie vermutet, dass dort die Angaben fehlen. Eigentlich ist eine Höhe Kronenform Durchmesser etc. definiert. Allerdings ist die 3D Umsetzung wahrscheinlich noch nicht implementiert. Oder es liegt ein anderer Fehler vor.

Okay, wenn man das Bild sehr zoomt, kann man tatsächlich ein Muster erkennen, das eventuell ein Fragezeichen sein könnte. Ich hatte dies eher als Textur betrachtet. Also doch analog der gemachten Aussage “Sorry, ich weiß es nicht besser”.

Ich bleibe aber bezüglich der Texturen bei meiner Aussage.

Wenn du das Plugin installierst, brauchst du nicht in dem fertigen Bild zoomen, sondern kannst dich frei im Raum bewegen und dann werden die Fragezeichen auch deutlicher.
Genauso wie die Fragezeichen auf den Wegen, welche die Außenkanten der Fußgängerzone bilden.