So die ersten Versuche sind getan. In Dresden Prohlis stehen nun einige 3D Gebäude und die Höhen sind eingtragen. Wenn ich eine Freigabe für die Luftbilder bekomme, würde ich auch gerne im Wiki eine Seite anlegen auf der ich meine Vorgehensweise beschreibe.
Allerdings kommen sofort Fragen und Wünsche auf, die unbedingt noch geklärt werden sollten.
Es ist mir nicht gelungen Erker/Balkone zu erstellen, welche nicht am Boden beginnen. Hier muss unbedingt nachgebessert werden und Beispielhaft gezeigt werden, wie die ganzen Parameter H1 D1 etc. zusammenhängen und dann auch eingetragen werden müssen.
Desweiteren ist es mir nicht gelungen Dächer vom Typ 0.1 zu erstellen. Einfach das gleiche Problem der Parameter.
Die bisherigen Häuser sind eigentlich mehrere in einander gestellte Gebäude welche dann als Hülle in etwa so aussehen, wie es in der Realität auch ist. Das Ziel wäre also auf den ersten Blick erreicht. Allerdings ist die Software flexible und man kann in die Gebäude eintauchen und hinter die Wände sehen. Gerade für Einkaufszentren und ähnliches wäre dies doch perfekt. Dafür dürften aber drinnen auch nur die Wände auftauchen, welche dahin gehören und nicht Hilfskonstrukte für eine schöne Außenhülle.
Die Eingänge würde ich nicht mit 3dr:entrace bezeichnen wollen, da diese Texturen auch für Fenster sehr gut sind. Außerdem muss unbedingt die Höhe in der diese Texturen beginnen sollen angegeben werden können. Auch Eingänge haben manchmal eine Treppe davor und beginnen nicht direkt am Boden.
Die Unterstützung von Multipolygonen ist wichtig. Eventuell wäre sogar zu überlegen die ganze 3D Beschreibung in Relationen auszulagern, damit nicht andere Software durcheinander kommt. Es sind auch Schlüssel hilfreich, welche offene Seiten bei Gebäuden ermöglichen. Wie zum Beispiel Tankstellen oder Bahnsteigdächer.
Außerdem sollten alle das Gebäude betreffende Schlüssel zusammengetragen werden. Ich kann mir vorstellen, dass die Anzahl der Stockwerke und und und alles schon mal irgendwo definiert wurde. Vielleicht sollte man auch nicht die Rooftabel als solche als Grundlage nehmen, sondern generell 3D Objekte als Einstieg und dann zu Gebäuden Bäumen ect. verlinken. Diese unterteilen sich dann wiederum in Gebäude allgemein (stockwerke Höhe…) Dächer und Anbauten.
Zu letzt würde ich mir noch eine Seite wünschen, in der klargestellt ist, welche 3D Schlüssel wirklich implementiert sind, wo ich also meine Fehler erkennen kann und welche 3D Schlüssel nur als Konzept vorhanden sind. Wie sieht die Unterstützung bei Straßenflächen aus? Werden surface ausgewertet? Kann man Fußwege anbringen. Vielleicht sogar mit Bordsteinkanten für die Oma mit dem Rollator oder den Rollstuhlfahrer. Aber bitte für solche Sache keine Strukturen entwickeln, welche die eigentlichen Wege in tausend Stücke teilen, nur weil mal rechts mal Links der Bordstein abgesenkt ist. So ein Projekt gab es ja bereits in Essen und ich halte das für wenig sinnvoll.
Hallo viw,
ich bin Dir, genauso wie allen anderen User die dieses Werkzeug unter die Lupe nehmen und die Spezifikation verbessern, auf zahlreiche Ungereimheiten und Fehler in der Spezifikation hinweisen SEHR dankbar. Zum einen freue ich mich, dass man die Thematik aufgreift was natürlich für mich und Kendzi ein Ansporn ist, zum Anderen ist es eine enorme Erleichterung wenn man sich nicht alles allein ausdenken muß, denn das Prinzip der OSM: Gemeinschaftswerk statt Insellösungen hat sich mehrmals bewährt und dazu geführt, das dieses Projekt weiter sehr schnell wächst.
Was die Umsetzung der Spezifikation angeht gilt das alte Prinzip: Wir haben mehr Ideen als Programmierer die es umsetzen können.
Dieses betrifft die Implementierung der Taggingschemata in dem PlugIn von Kendzi. Zum Glück kann der Kerl (der privat absolut nett ist) kein Deutsch also kann ich nur sagen, dass Kendzi dermaßen mit Ideen und der Arbeit zugeschüttet ist, dass die Implementierung zwar zuverlässig, aber nicht sofort geschieht.
Es gibt seh wohl Programmierfehler mit einzelnen Dachtypen. Diese BITTE direkt dem Kendzi mitteilen.
SEHR GUTE HINWEISE: Höhe von dem Eingang für die Texturierung - Klasse Idee, setzen wir in absehbarere Zukunft um!
Differenzierung zwischen Eingang und Fenster ( auch für die Texturierung): Bitte um Taggingvorschläge!
Relationen sind eher ungeliebt, da das System selbst für Anfänger idealerweise selbsterklärend sein sollte. Auch hier bitte um einige Ideen wie das praktischerweise laufen könnte.
Zusammenstellung der Schlüssel: GENAU! Ich habe gestern Nachmittag die ersten Skizzen dafür gemacht mit der Absicht nächste Woche die neue Wiki Seite: http://wiki.openstreetmap.org/wiki/3D_building damit zu füllen. Irgendwie dedenkt man gemeinsam in die gleiche Richtung… Die Beschreibung kommt bald.
Deine Anregung beinhaltet noch mehr. Ich werde darauf heute Abend antworten.
Bis dahin ist es wichtig so viel 3D Karte wie möglich zu schaffen.
Warum? Appetit kommt mit dem Essen. 
Wie ich schon mal geschrieben habe, entwicklete ich mitte 90-er die ersten 3D GIS Konzepte in Deutschland, war Berater von Regierungsbehören und war Mitbegründer von SIG-3D. Ich muß bei aller Erfahrung gestehen: die Freiheit, Freiheit im Geiste die von OSM kommt ist atemberaubend! Für mich ist schon klar, dass sie kommerziellen Kozepte von gestern sind. Die Datenabdeckung und Aktualität der Daten führte schon OSM zu vielen Erfolgen. Ich schätze mal, dass 3D zum Ausschalten kommerzieler Konzepte im Bereich der Geodaten führen wird.
Beste Grüße
Marek
Ich habe mich heute mal rangesetzt und niedergeschrieben wie ich ein 3D Gebäude erstellt habe. Ich würde es sehr gut finden, wenn wir über den Weg diskutieren und so vielleicht erste Lücken in der Definiton feststellen.
http://wiki.openstreetmap.org/wiki/User:Viw/OSM3D
Das Gebäude des Worshops ist übrigens hier entstanden: http://www.openstreetmap.org/?lat=51.040507&lon=13.771552&zoom=18&layers=M
Gute Arbeit. Mehr am Abend.
Beste Grüße,
Marek
Also ich denke das es keine Differenzierung zwischen Eingang und Fenster braucht, wenn wir die Höhe angeben können und das Fenster nicht am Boden beginnt, ist das ja kein Problem. Aber irgendwie müssen wir mehrere Fenster übereinander darstellen können.
Naja meine Idee war einfach, dass man offene Unterstände zeichen kann. Diese sind allerdings nur dann offen, wenn man eine Seite wegläßt. Damit werden sie aber bei Mapnik nicht mehr dargestellt. Irgendwie schwierig also:
http://www.openstreetmap.org/?lat=51.005345&lon=13.799547&zoom=18&layers=M
Außerdem sind Multipolygone wichtig für solche Gebäude:
http://www.openstreetmap.org/?lat=51.007269&lon=13.804386&zoom=18&layers=M
Die Schule taucht leider in der 3D Darstellung nicht auf.
Ein erstes Problem bei der Spezifikation mit den Fenstern/Eingängen taucht auf, wenn man diese in Zusammenhang mit Erkern verwenden möchte. Diese werden ja eigentlich nur um einen Punkt herum dargestellt. Das mache ich mit einem Fenster dann wahrscheinlich auch. Allerdings ist das Fenster dann in der hinteren Wand und wird vom Erker verdeckt.
Durchaus verständlich beschrieben. Mit den Bildern hast du dir ja auch einiges an Arbeit gemacht!
Was mir allgemein aufgefallen ist: Gibt es einen Grund, warum immer noch Gebäudeteile als komplette Gebäude erfasst werden? Es existiert doch schon seit längerem der Vorschlag, dort mit building:part=* statt building=* zu arbeiten. Es erscheint mir auch nicht allzu schwierig, das in einem 3D-Renderer zu unterstützen; als erste Annäherung behandelt man beide Tags einfach erst einmal gleich. Gibt es also konzeptionelle Vorbehalte dagegen? (Frage in die Runde.) Sonst habe ich nämlich vor, das sehr bald mal in OSM2World einzubauen.
Da du die Stockwerke ja eh schon gezählt hast: Spricht etwas dagegen, sie zusätzlich mitzutaggen? Im Gegensatz zu der Höhe wäre das ja ein exakter Wert. Oder hast du das nur der Einfachheit halber weggelassen?
Und die Sache mit den Eingängen … na ja, das ist ein Hack, Taggen für den Renderer. Funktioniert bei Kendzi, anderswo eher nicht. Aber das ist ja klar, oder? 
Danke für das Lob. Ich habe einfach nur meine Erfahrungen damit wiedergegeben. Der Vorschlag war auch das building:roof:oriel=1 zu taggen. Nur leider bekomme ich dann keine Ergebnisse, wenn ich das so probiert habe. Daher habe ich es erstmal mit building=yes gelassen. Der Renderer macht übrigens von ganz allein auf alle Häuser ein Flachdach, weswegen ich auch das weggelassen habe.
Aus meiner Sicht spricht nichts gegen diesen Tag. Allerdings ist auch die Frage ob er notwenig ist, wenn die Sache sich mit building:roof:oriel=1 darstellen lässt.
Spannend an dem kendzi3D finde ich das man sich auch in die Häuser reinbewegen kann und da sollten dann nur geplante Wände stehen. Bei den meisten Häusern sind vertikale Wände ja übereinander.
Ich habe das nicht der einfachheit halber weggelassen, sondern nur weil die Schlüssel dafür nicht zu finden waren. Es spricht nichts dagegen, diese hinzuzufügen. Gerne auch bei anderen Häusern.
Wahrscheinlich ist es tagging für den Renderer. Aber da ich nicht so versiert im Umgang mit diesen 3D Tags bin, habe ich erstmal nach Auge gearbeitet und nicht so sehr nachdem was die Vorgaben sind. Daher bitte ich auch um konkrette Verbesserungen. Übrigens der Eingang war hier zum ersten mal dabei. Das habe ich vorher bei Unterständen an der Haltestelle entdeckt.
Die Frage ist ja auch inwiefern man Dinge neuerfinden muss, welche schon anders heißen. Dazu würde ich zum beispiel Ticketautomaten und Stromkästen zählen, welche vereinfacht als Quader dargestellt werden können und dann vielleicht nur einer Beschriftung bedürfen.
Ich hatte heute übrigens die Idee ein Einkaufszentrum in 3D zu erfassen. Damit könnte man vieleicht auch um finanzielle Unterstützung werben. Vorallem wenn man dann Indor mapping betreibt und man dann die Geschäfte finden kann. Wie gesagt das Plugin er möglicht diese Ausflüge schon. Nur sind meine Häuser noch etwas leer.
Man kann als Gebäudeteile sehr viel darstellen, auch Dinge wie Gebäudebrücken und “schwebende” Gebäudeteile (Beispielfoto) im Zusammenspiel mit min_level/min_height. Das Konzept hätte also ein recht breites Anwendungsgebiet, es ist letztlich ein universeller (wenn auch denkbar primitiver) Ansatz zur Modellierung von Teilvolumen eines Gebäudes.
Prinzipiell ginge meine Überlegung eher dahin, auch Erker und dergleichen als Gebäudeteile mit entsprechendem Wert für building:part=* - also insbesondere als Way anstatt als Node - darzustellen. Dann hat man dort nämlich auch einen Umriss, den man ganz normal mit Fenstern & co versehen könnte.
Aber ich warte besser jetzt erst mal ab, was Marek zu deinem Artikel sagt. 
Am verbreitetsten ist wohl building:levels (428 702). Das stammt aus einem früheren Building-Attribute-Proposal.
…Und die Sache mit den Eingängen … na ja, das ist ein Hack, Taggen für den Renderer. Funktioniert bei Kendzi, anderswo eher nicht…
Ekhm, momentan funktioniert es nicht mal bei Kendzi. Es funktioniert noch nirgendwo genauso wie 60% von dem vorläufigen Proposal “roof table”. Das ganze ist, wie auf dieser Seite zu lesen, ein Teil von dem Konzept OSM-4D. Kendzi3D ist ein Tool mit dem zwar Einiges möglich ist, vor allem aber der sichtbare Nachweis geführt werden kann, dass diese Art von dem Tagging in ein 3D Modell umsetzbar ist und für dei meisten Gebäude mit einfachen Strukturen zu einem zufrienden stellenden Resultat führt.
Unabhängig von Kendzi 3D arbeitet (wie ich bereits geschrieben habe) ein Team an einem Modelliertool in 3D was wesentlich umfangreicher sein wird als Kendzi 3D.
Für OSM-4D ist building:levels ein Teil der Definition genauso wie Indoor mapping sowie das Nachzeichnen der Gebäude so wie Tordanik es umgesetzt hat.
So gesehen ist OSM-4D gedacht als eine Möglichkeit für mehrere Viewer: Kendzi3D, OSM2World und viele Andere.
Hi viv,
zu Deinem Text:
-
Differenzierung zwischen Eingang und Fenster: Ziel sind in Zukunft dynamische Level of Detail: Die Fensterreihen werden entfernungsabhängig in dem Echtzeitviewer in 3D früher weggelassen als die Eingänge: Es entspricht der menschlichen Wahrnehmung:
bei den Gebäuden, die näher sind, sehen wir mehr, bei denen am Horizont nur die Umrisse. TEchnisch wir es 3-5 Zonen geben, in denne nach und nach Gebäudedeteils weggelassen werden, damit man mit so großen Datenmengen ich Echtzeit hantieren kann. -
offene Unterstände sind in OSM-4D möglich. Die “roof table” ist bereits jetzt, wie Tordanik richtig schrieb" so überladen mit Inhalten, dass kaum für jemand verständlich. Ich muss das alles umbauen. Ich wiederhole nochmal: es wäre nicht schlecht, sich gemeinsam zu treffen und besprechen wie man es am schlausten macht.
Ich bin der Meinung am Besten macht man das wenn man alles auf verschiedene Seiten aufteilt. Dann kann man in einem Index nachschauen, ich brauche einen Balkon und klickt auf den Link.
Wenn man ein Spitzdach braucht klickt man auf einen anderen Link.
Zusätzlich würde ich noch typische Gebäude wie auf der ersten Testseite als tutorial nachbauen und dort die ganzen Links und Möglichkeiten erklären. Damit andere auch mitmachen und sich dafür begeistern, sollte das Renderingplugin diese Sachen unterstützen.
Dann kann man nämlich prüfen ob man sich verschätzt hat oder ob es so verstanden wurde wie man sich das vorgestellt hat. Das ist ganz wichtig. Bei 2D sehe ich ja auch in Josm schon was eingetragen wird, wenn auch viele Details nur mit Piktogrammen dargestellt werden.
Außerdem solltet ihr für das Rendering in 3D unbedingt Stylefiles vorsehen, damit man nicht an den Programmcode muss, wenn einem die Farbe der Straße nicht gefällt. Das ist mit bei highway=livingstreet aufgefallen.
Naja dann ist doch das einfachste diese Texturen mit window statt entrace zu taggen und fertig. Meine Meinung. Wobei sicher bei Glasfasaden alles ein Fenster ist und dann nicht weggealssen werden sollte.
Das ist wirklich schön, dass es in osm4D alles kommt. Ich weiß ja das die armen Programmierer auch nur Menschen sind. Manche von denen sollen ja sogar eine Familie haben.
Eine ganz knifflige Frage die sich mir noch stellt ist wie wir das Gelände in die Anwendung bekommen und wie dieses dann berücksichtigt wird. Denn gerade in Prohlis scheinen die Gebäude auf dem Foto unterschiedlich hoch zu sein. Allerdings steigt das Gelände unmerklich an, so dass bei länderen Häuserzeilen immer wieder Sprünge von 2 bis 3 m auftauchen, obwohl die Geschoßzahl und Bauweise identisch sind.
Gibt es bereits Tools, mit welchen man m-genau Daten in Josm erzeugen kann? Ich meine wenn wir jetzt schon mit 3D anfangen und dann höhe breite Länge des Gebäudes bestimmen können/müssen, dann wäre es doch unsinnig diese freihändig in Josm vom Luftbild abzumalen.
So heute habe ich mich mal daran gemacht und einen ersten Versuch unternommen Schrägdächer auf das Haus zu setzen. Allerdings habe ich dabei einige Überaschungen erlebt.
http://wiki.openstreetmap.org/wiki/File:OSM3Dworkshop_1.1.png
während die 3 Gebäude in der Mitte eigentlich erwartungsgemäß aussehen, sind die beiden querstehenden links genau falsch rum. Warum? Das Eckhaus ist noch spannender. Hier sollte eigentlich auch das Dach um die Ecke gehen.
Alles ist so, wie Kendzi es programmiert hat. Die BEschreibung beinhaltet noch nicht die Darstellung aller Fälle. Am besten direkt bei ihm nachfragen was Sache ist: Die Bugs und Überraschungen sind wertvoll denn sie zeigen, wie jemand, der gerade dmait beginnt, arbeitet, und was ihn stört.
Was in dem PlugIn fehlt ist eine gut strukturierte Help Funktion.
Beispielsweise für das Gebäude Typ 2.0 auf dem L-Grundriß wird das Dach auf einem Bounding Box Gesamtbreite x Gesamttiefe angelegt und daraus erst Teile entfertn. Dann sieht ein Eegebnis so aus, wie es aufd dem von Dir angehängtem Beispielsbild aussieht.
Eine Funktion für Dächer Types: 1.0 und 2.0 für Gebäude in Form mehrmals gebrochener Linie ( z.B. für eine Z, N, M, U Form) mit der Funktion “entlang des Verläufes generieren” ist noch nicht implementiert. Es wird aber kommen.
Das ist doch normal! Der Programmierer dokumentiert frühstens wenn er fertig ist. Außerdem ist ja auch noch nicht alles spezifiziert. Wie soll es da schon in der Hilfe sein.
Naja der Typ 9 sah mir schon nach sowas aus. wenn ich den aber versuche wird nichts mehr angezeigt. Vielleicht weil es noch nicht implementiert ist.
Kompliment dafür, dass die Keytabelle angepasst wurde. Jetzt kann man endlich was mit den Höhen und Längen anfangen. Die Bildchen sind auch gut beschriftet. Man findet also auch schnell die betreffenden Dinge und es scheint bis auf wenige Ausnahmen auch zu funktionieren. Bei Dachtyp zwei hat mich die Einteilung etwas irritiert. Ich hatte nach 2.0 als 2.1 eigentlich den Typ 2.4 erwartet. Ich denke der wird wesentlich häufiger zu finden sein als die anderen beiden Vertreter. Es sei denn, man baut Häuser dann aus Einzelelementen zusammen. Sonst dürfte der Typ2.1 nur als Anbau vorkommen nicht aber als Hausdach an sich.
Eventuell ist noch von Bedeutung bei den Tags für die Höhen und Breiten, dass man erkennen kann, wann die für das Haus sind und wann die für Gauben oder Anbauten gelten. Vielleicht wäre es sinnvoller, an jeder Tabelle nochmal den Grundschlüssel anzugeben.
Ich gebe zu dass ich mit der Reihenfolge einiger Gebäudetypen nicht zufrieden bin. Besser gesagt: Vieles ist zwar nach reichlicher Überlegung aber die Reihenfolge nach Schnauze. Wir müßten prüfen, ob schon jemand mit diesem Typ gearbeitet hat. DEnn wenn wir jetzt Typologie umschreiben, kann es zu Fehler füren, wenn irgendwo vertreten.
… Vielleicht wäre es sinnvoller, an jeder Tabelle nochmal den Grundschlüssel anzugeben… Warum nicht. Machst Du einen Vorschlag?
Ein sinnvoller Tagging ist hier enorm wichtig und wir sind un mmit Kendzi sehr unsicher was das angeht…
Ich denke vielleicht sollte man die Nummerierung wirklich nicht mehr ändern. Aber wenigstens die Reihenfolge in der Tabelle dann vielleicht.
Wie würden denn bei dir zwei Balkons über einander aussehen? Als Tags meine ich.
Wenn zwei oder mehrere Elemente die identisch sind, übereinander liegen, müsste der Punkt einen Tag erhalten der sinngemäß “number of…=value” heißen müßte. Danach von unten aus: balcony1:height=value, balcony2:height=value usw… Spezifiziert haben ich das aber noch nicht.
Elegant wäre ( auf den ersten Blick) nur die Anzahl der Elemente und den wiederholbaren Abstand dazwischen anzugeben, damit alle anderen den gleichen Abstand bekommen. Leider sind oft die Geschoßhöhen leicht unterschiedlich ud auch für diesen Fall muß man sich was ausdenken.
Irgendwelche Vorschläge?