Workshop OSM 3D

Edit: Inzwischen ist ein erster Entwurf der Wikiseite online: http://wiki.openstreetmap.org/wiki/User:Viw/OSM3D

Hallo, von den ersten Bildern angestachelt wollte ich doch jetzt selbst erste Versuche mit 3D bearbeitung in OSM machen.
Das Plugin Kendzi3D (http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Kendzi3D) scheint zwar mit dem WindowsXP noch Probleme zu haben, unter Windows7 konnte ich aber erste Ergebnisse sehen. Die Bewegung in OSM 3D ist allerdings auch nicht einfach, aber wenn man erstmal heruasgefunden hat wie es geht kommt man damit klar.
So aber nun zum Thema Marek möchte gerne, dass wir vielen Menschen die Möglichkeit bieten 3D Daten einzutragen. Dafür sollte das ganze aber möglichst gut und anschaulich erklärt werden.
Allerdings ist die Vorraussetzung das man es mitbearbeiten kann, dass man versteht was man dort tut. Daher habe ich mir ein Plattenbaugebiet mit möglichst einfachen Struckturen gesucht. Aber schon bei den ersten Hochhäusern komme ich nicht weiter.
Um diese Stelle hier geht es:
http://www.openstreetmap.org/?lat=51.004281&lon=13.79864&zoom=18&layers=M
Es handelt sich dabei um Turmähnliche Gebäude welche vom dem Typ sind wie diese
http://phila3000.de/JPGS/ch/ch25000-29999/ch26098.jpg
Eine bessere Seitenansicht von der Spitze hier:
http://www.dd4kids.de/uploads/Ballplatz/Leuben_9002.jpg
Außerdem gibt es sehr gute Luftbilder von Aerowest
Als Adresse einfach die Prohliser Allee 31 suchen.
Wie also soll man vorgehen damit das Dach wirklich in 3 Stufen (Haupthaus, Treppenhaus, Vorbau/Eingangsbereich) hinbekommt.

Warum nicht Arbeits-Geschäft?

Die Aufbauten die höher sind als die Standardhöhe eines Wohngeschosses können mit dem Werkzeug building:roof:oriel=1 mit dem Wert: min_height:24 und geschätzter Höhe von 3 Meter über die Ebene des Hauptdaches height:27 getaggt werden.
In diesem Fall müßte der Umriss der Aufbauteilen jeweils über dem Umriss des Grundrisses gezeichnet werden etwa:


| |
| _____ |
| | | |
| | | |
| |____ | |
|_____________ |

Die letzte Entwicklung die noch auf (momentan) roof table Seite kommt, sind die Eingangsbereiche.
Ich merke aber, dass aus der einfach lesbarer Dachtabelle
eine SEHR umfangreiche Seite die eigentlich nichts anderes ale ein ausgebautes Konzept zum Modellieren der 3D Gebäude darstellt geworden ist.

Ein Umbau auf einige Wiki Seiten ist also erforderlich, inclusive viele, sehr viele Gebäudebeispiele.

Falls jemand von Euch gut in Gestaltung von Wiki Seiten ist, würde ich mich gern treffen und die Sache besprechen.
Ich habe bereit enorm viel Zeit investiert und midestens das dreifache ist noch ntwendig damit die Sache glatt, durchdacht und leicht zu verstehen ist…

So ich habe es mal versucht umzusetzen. Es sieht in der 3D Ansicht gut aus. Alelrdings bin ich mir nicht sicher ob ich dich richtig verstanden habe und es richtig umgesetzt ist. Ungünstig finde ich, dass die inneren Teile ebenfalls mit building=yes getagt werden müssen damit es dargstellt wird. Eventuell kann man das ja auch ohne erreichen. Damit es nicht zu Konflikten mit anderen Datenauswertern kommt die dann mehrere Gebäüde übereinander sehen würden.

Die innerhalb eines Umrisses liegende Subelemente eines Gebäudes sollen (geplant) ohne diesen Tag auskommen. Die Entwicklung der Software ist aber langsamer als unse Appetit ,) Ich würde auch am liebsten schon alle Funtionen imppementiert haben aber die Art WIE man was implementiert bei so großem Projekt bedarf der Zusammenarbeit und Absprache innerhalb von OSM. DEnn sonst machen wir zu zweit alles so, wi wir es für richtig halten und werden Einiges wohl außer acht lassen.

Auch wegen dem Tagging wäre ein Treffen und Gesprächsrunde nicht verkehrt. Leider ist es bei diesem Fall so, dass man alles implementeieren müßte damit man eben die meisten Gebäudeformen abdecken kann.

Also: ein Workshop in naher Zukunft an alle interessierte…

In der Tat 3D kann süchtig machen. Und es ist vieles auch noch nicht implementiert. Zum Beispiel Straßenbahnschienen und Co. Aber ich denke von diesem Stadtteil kann man ganz schnell einen guten Überblick bekommen. Wenn jetzt auch noch die anderen Gebäude wachsen, sieht es dort schon ganz nett aus. Das Problem wird dann nur wenn es kompliziertere Strukturen werden. Ich vermisse zum Beispiel Die Hausdurchlässe, wo die Fußwege hindurch führen. Desweiteren wären Haltestellenschilder und Unterstände sehr nett. Wir wollen ja noch gar nicht davon reden was man da alles drauf schreiben könnte. Und wenn du dann erst die Straßenbahnen in echtzeit fahren lässt, dann haben wir denke ich ganz klar die Nase vorn!

Hausdurchlässe sind bereits vorgesehen, aber nicht implementiert. Künstliche Verläufe entlang einer Kurve im Raum mit vordefiniertem Profil sin ein Teil der OSM-4D Beschreibung und müssen ebenfalls implementiert werden. Die Verbesserung von dem Gelände ist aber eine andere Baustelle: wir haben zunächst mal als Schwerpunkt Gebäude. Je mehr vorzeigbare Masse wir aber produziert haben, umso leichter wird es sien in der Community Programmierer zu finden, die die angefangene Arbeit unterstützen.

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. :slight_smile: :slight_smile: :slight_smile:

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? :wink:

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. :slight_smile:

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.