Ich tagge einfach die Stockwerkanzahl, die ist nämlich immer leicht ersichtlich. Die Höhe tagge ich eigentlich nur bei Kirchen oder ähnlichem wo die Höhe bekannt ist (z.B. via Wikipedia). Und wenn ich etwas mit Höhe taggen will wo die Stockwerkzahl unangebracht ist, verwende ich est_height und schätze die Höhe anhand von Nachbargebäuden oder ähnlichem.
Das passt dann auch zu OSM2World: Es sucht erst nach dem height-tag, dann nach est-height. Ist beides nicht vorhanden wird die Stockwerkzahl als Abschätzung verwendet.
Bzgl. Farben habe ich auch noch kein brauchbares System zumal ich mit dem Farbcode nicht so ganz zurecht komme. Die Farbe im gerenderten Zustand sieht dann doch immer wieder etwas anders aus als ich es mir gedacht hatte. Daher verwende ich nur die Grundfarben: green, yellow, red, …
bevor ich jetzt raus gehe und anfange komplexe Dächer (https://wiki.openstreetmap.org/wiki/Roof_table) zu taggen und vermessen und Fassaden fotografiere oder sonst was - ist ja ein verdammt aufwändiges Stück Arbeit - würde mich interessieren, ob die Arbeit nicht in 2 Jahren umsonst war, weil ein neues 3D-Schema kommt oder so. Ich meine, was ist jetzt wirklich nutzbar und das in absehbarer Zeit auch gültig. Mein (geringer) Überblick sagt mir was von mindestens 2 verschiedenen 3D-Schemata. Woran sollte man sich halten. Wie gesagt, habe keine Lust, jetzt Tage Arbeit zu investieren, um am Ende zu sehen: Uups, schade, das andere Schema wurde allgemein anerkannt und kennt derlei Tags nicht. Vorher tagge ich nämlich lieber weiter Hydranten
2.) Das Schema das unterliegt, kann ziemlich leicht “portiert” werden… (wir sprechen von Dachformen, deren Linien alle eindeutige Namen haben und auch in einem anderen Schema wieder an der selben Stelle auftauchen müssen…)
Somit glaube ich, dass Dinge wie diese sehr leicht getagged werden können ohne Gefahr zu laufen, dass die Taggings verloren gehen…
Das 3dr-Schema nach der von dir erwähnten Wiki-Seite wird sich wahrscheinlich in der jetzigen Form nicht durchsetzen. Dafür ist es viel zu kryptisch für die meisten Mapper. Auf der anderen Seite ist es mit dem prefix “3dr:” klar zu erkennen, so dass es relativ leicht sein wird, das zu einem Nachfolger oder einem anderen 3D-Schema zu ändern (tunnelbauer erwähnte das bereits).
Was mit großer Wahrscheinlichkeit Bestand haben wird, sind die Simple 3D Buildings. Die sind einfach genug, um ohne jedesmal Nachschlagen zu müssen, eingetragen werden zu können. Dafür gibt es dann eben nur eine kleine Auswahl von gängigen Dachformen. Für komplexere Dachformen muss man dann als Ergänzung etwas anderes zur Hilfe nehmen.
Hallo S-Man42,
ich verstehe Dich wirklich gut. Als Autor des 3dr-Schema von dem auch die Simple 3D Buildings (Dachformen) abgeleitet wurden, kann ich nur sagen, dass ich selbst momentan kaum in 3D mappe, weil es viel Arbeit ist und ich kann die Ergebnisse nicht sofort sehen, bzw. in 3D modifizieren.
Ich warte noch bis ein Editor entsteht der komfortabler ist. Ich versuchte ja auch eine Testentwicklung in diese Richtung an der TU-Lodz zu Ende zu bringen. Solange die Jungs dort 24 Monate Zeit haben um die Dissertationen abzuschliessen, liegt die Entwicklung brach. Vielleicht wird Tordanik / Kendzi in aller Ruhe Schritt nach Schritt soweit sein bevor sie durch sind.
Wenn die Anzahl der Stockwerke berücksichtigt wird, ist das ja ausreichend. Dann brauch ich ja keine Höhen raten.
Bei vielen Häusern (Wohnblöcken) ist der Keller halb über dem Erdboden. Wird das irgendwie berücksichtigt?
Eigentlich sollte es berücksichtigt werden. (Ohne in Wiki geschaut zu haben).
Nur- ein Hinweis an alle: die OSM Community sowie Firmen, die kommerziel Daten erheben: die 3D Darstellung basiert auf der Anzahl der Stockwerke funktioniert zwar und sieht sogar nett aus, hat aber mit der Realität unter Umständen wenig zu tun. Es ist sozusagen das allermideste was man machen kann um überhaupt den Eindruck zu erwecken, dass man 3D Daten hat.
Ich konnte während meiner Arbeit mit dem 3D Modell von Hamburg gesehen, dass das Modell welches auf der Anzahl der Stockwerke basiert, derart Müll ist, dass man es nur für die ganz grobe Visualisierung verwenden kann.
Gründe:
Sehr verschiedene Höhen der Stockwerke, teliweise Erdgeschoß höher als die anderen Stockwerke
Halbe Stockwerke (Suterrain) sowie Dachböden die zwar kein Stockwerk sind aber trotzdem zu der Fassadenhöhe beitragen.
Gebäude am Hang: Auf der einer Seite ein Stockwerk mehr oder weniger. Die “Höhe” hängt davon ab, von wo man die Anzahl der Stockwerke zählt.
Gebäude mit einem künstlichen Sockel
Oft haben Kirchen, Industriehallen ein bzw. 2 Stockwerke. Dort weichen beim Rendering die Höhen am meisten ab.
Mein Rat an verrückte die 3D mögen: Billigstes Entfernungsmessgerät (Laser bzw. Ultraschall). Ich habe 1998 mit einer Gruppe von Teenies aus Krzywin ( http://osm.org/go/0Mv_PBZL , ca. 1800 Einwohner, 90% der Stadt in SOM nicht vorhanden ) Gebäude in dem ganzen Städtchen innerhalb von 4 Tagen vermessen - jeweils First und Traufe. Anschliessend bauten wir ein 3D Modell der Stadt in einem CAD Programm auf. Ich habe wirklich Lust dies irgendwo in Deutschland zu wiederholen. Es wäre eine schöne Mapping Party…
Die building:levels=n Anzahl. Ich glaube wie viele das jeweils an der Wand sind, kann man derzeit (noch) nicht regeln.
Bitte bedenken, dass man mit parametrisierbaren 3D Modellen nicht 100%ig (mit realistischem Aufwand) alles an einem Gebäude nachbilden kann. Hebt am besten die Fotos auf, dann kann man die später für “richtige” indivituelle 3D Modelle noch mal nutzen.
osm2world wertet das building_part=yes aus, klar. Sonst wären die Abschnitte der Häuser nicht unterschiedlich gefärbt - z.b. in Graz.
ABER die Buildings sollten dann in einer Relation type=building sein.
Und ich hab ne Frage: Häuser in L-Form, wo der Dachfirst in L-Form ist, hab ich eigentlich als 2 Rechtecke getaggt mit building:parts=yes und einmal roof:orientation=along und am kurzen =across. Oder beim Kreuz etwa so: http://www.openstreetmap.org/browse/relation/2734736
Nun kam mir die Idee: man sollte die building:parts doch am besten an der Schnittkante der Dächer entlangführen, damit keine hässlichen Lücken entsthen.
Somit sieht das dann so aus: http://www.openstreetmap.org/browse/relation/2740729
Gibt die letztere Variante Probleme? IMHO ist sie besser.
Das mit der Datenänderung ist technisch etwas doof. Das Datum der Änderung (das in der About-Seite) ist das Datum vom letzten Download von Frederiks Dumps. Die Daten sind zu diesem Zeitpunkt normal schon ca. 1 Tag alt. Das neu rendern bezieht sich dann immer auf die heruntergeladenen Daten. Bis deine Änderungen vom Sonntag drin sind kann daher derzeit bis zu einer Woche vergehen.
Ich bin mir bei beiden Varianten nicht so wirklich sicher, da das ja doch etwas “Tagging für den Renderer” ist. Ich nehme building:parts eher bei bauartlicher Trennung, unterschiedlichen Höhen,… her. Was aber immer klappt und von OSM2World auch so unterstützt wird ist das Proposal von Aschilli mit Roof Lines.
Edit: Wie auf dem 2. 3D Workshop in Garching vereinbart unterstützt OSM2World übrigens eine leicht modifizierte Version von Aschillis Vorschlag: Das ‘building:’-Präfix wird weggelassen.
Bei PNG-Output brauchst du zusätzlich noch Kameraparameter, die einfachste Form ist tilebasiert (–oview.tiles ,,). Genaue Dokumentation im Wiki.
Mit deinem Aufruf wirst du außerdem keine Texturen haben - falls dich das stört, kannst du dir die Beispieltexturen herunterladen und über --config einbinden. Für einen ersten Test ist das aber nicht nötig.
Zu den Fehlermeldungen: Bestimmte Exceptions entstehen durch Mappingfehler, Rechenungenauigkeiten oder andere Probleme und werden dann ignoriert und nur auf der Konsole ausgegeben. Dann steht normal was von “Ignored exception” davor. Die eigentliche Konversion läuft aber trotzdem weiter, nur das eine betroffene Objekt wird ggf. nicht (vollständig) dargestellt. Also solange es kein sichtbares Problem mit der Ausgabe gibt, sind die meisten Exceptions nicht weiter schlimm.
Wozu soll das gut sein, wenn wie bei meinem Beispiel die komplette Fläche des Gebäudes durch building:part abgedeckt ist?
Wenn nur einzelne Teile mit building:part markiert sind, mag das ja sinnvoll sein, aber bei einer kompletten Abdeckung sollte das meiner Meinung nach nicht notwendig sein.
Irgendwie habe ich das Gefühl, dass immer wenn jemand nicht genau weiß, wie etwas gehen soll, eine Relation als Allheilmittel vorgeschlagen wird. Wer soll die alle berücksichtigen/auswerten?
An Tordanik und Peda geht die Frage:
Ist eine Gebäude-Relation notwendig oder wird das (zur Zeit) gar nicht ausgewertet?
Falls die notwendig ist, ergänze ich die natürlich noch.
) Gebäude in dem ganzen Städtchen innerhalb von 4 Tagen vermessen - jeweils First und Traufe. Anschliessend bauten wir ein 3D Modell der Stadt in einem CAD Programm auf. Ich habe wirklich Lust dies irgendwo in Deutschland zu wiederholen. Es wäre eine schöne Mapping Party…