Zwei Arten der 3D Objekte.Generalisierung+Indoor mapping

Bei der zukünftigen Modellierung der 3D Objekte, vor allem Häuser, kann man davon ausgehen, dass Mapping der Massendaten auf der Grundlage von Begehung im Freine sowie (wenn vorhanden) Luftbilder geschieht.

Ohne entsprechende Vermessungswerkzeuge werden diese Daten ungefähr, aber trotzdem ausreichend die dreidimensionale Welt abbilden.
Wenn man über die Häuser redet, ist der Gedanke dass ALLE Häuser mit Innerräumen (Indoor Mapping) erfasst werden, eher unwahrscheinlich.

Viel realistischer ist die Annahme, dass öffentliche Bauten wie Einkaufszentren, Flughäfen, Bahnhöfe, Krankenhäuser, interessante Kirchen etc. mit Innenräumen erfaßt werden.
Insbesondere die Erfassung der Innenräume privater Häuser wird mit ziemlicher Sicherheit auf Widestand stößen (ich selbst wäre dagegen).

Die Untersuchungen der Baustrukturen die wir an der TU Hamburg vor einigen Jahren durchgeführt haben zeigten, dass mehr als die Hälfte der Bausubstanz aue einfachsten geometrischen Formen (Rechteck+ Flach bzw. Doppelschrägdach mit diversen Gauben) besteht. Es sind in der Regel Objekte für die man kein Indoor Mapping benutzen wird.

Wenn man 3d Objete verwendet, produziert man enorme Datenmengen. Jede Art der Beschreibung die die Kompressionsraten der Daten erhöht hilft nachher bei der Echtzeitvisualisierung, Upload etc.

Daher hat das Konzept der Modellierung der Gebäude in OSM-4D zwei Arten der Modellierung vorgesehen: Gebäude als Symbol (Kendzi3D) und eine 3D CAD - nahe Darstellung in der Indoor Mapping möglich ist: ( Geschoße, Wände, 3D Treppen, 3D Öffnungen, Fenster und Türen).

Leider ist die Umsetzung eines solchen Systems ein recht großes Projekt. Hinzu kommt, dass wenn man in einer kleinen Gruppe programmiert und anschließend der Community einen so großen Brocken auf einmal wirft, dann kann man sich nicht wundern, dass das Projekt sich extrem langsam durchsetzt. Leider ist der Part “Echter 3D Modeller” ziemlich schwer ohne eines Grundkonzeptes zu verwirklichen. Werden wir die ersten Teile haben, könnt Ihr sie genüsslich zerreißen bzw. mitmachen. ,)

Hi Marek,

naja die Idee von meinem 3D Objektkatalog habe ich ja immernoch, nur die Zeit fehlt mir
http://wiki.openstreetmap.org/wiki/Open3DMap
Ich denke das wäre aber immernoch einer der besten Möglichkeiten, um auch die 3D Modeller Communities dort abzuholen, wo sie sind: bei IHREN Programmen.

Du sagst ja selber, dass ein 3D Modeller alles andere als trivial ist, daher sollte man wirklich ganz einfach anfangen und erstmal 1:1 Zuordnungen von OSM<->COLLADA erlauben. Und die kann dann jeder erstellen womit er mag.

Die Idee ist schon nicht schlecht, nur als Praktiker kann ich Folgendes sagen:
Freie 3D Modelle sind sehr oft:

  1. Ohne richtige Drehung sonder einfach entlang X-Y Ache ausgerichtet
  2. maßstabslos ( nachträgliche Skalierung erforderlich)
  3. Nehmen keine Rücksicht auf benachbarte Gebäude. Dadurch kommt es meistens, wenn man mehrere Objekte nebeneinander hat, zu Überschneidungen die extrem störend sind.
  4. Die Modelle nehmen keine Rücksicht auf Geländeverlauf sonder generalisieren Erdboden als flache Ebene. Auch wenn das bei geschätzt 2/3 der Objekte nicht auffält, ist es dennoch schwierig, wenn man ein 3D Modell inklusive Gelände anstrebt.

Daher ist die Idee 3D Modelle per Link in OSM zu integrieren zwar als Anfang gut und wurde schon von Vielen geäußert, jedoch für die Zukunft wäre sicherlich ein eigenes Erfassungswerkzeug besser:

Statt außerhalb von OSM arbeiten zu lassen der OSM Gemeinschaft ein Arbeitswerkzeug zur Verfügung zu stellen, welches die 3D Fans richtung OSM zieht.
Entsprechende Exportfilter aus OSM in andere Formate werden die Leute dann auch entwickeln.

Google scheint das alles nicht zu stören und sie rekrutieren mit diesem Ansatz derzeit eine Modeller-Community, die wir eigentlich lieber bei einem freien Projekt sehen würden.

Ausrichtung, Maßstab und Gelände-Ansatzpunkte eines Modells zu definieren sollte doch machbar sein? Die Interaktion mit benachbarten Gebäuden ist sicher schwer in den Griff zu bekommen. Allerdings spielt das bei freistehenden Objekten (und viele der markantesten Objekte gehören meiner Vermutung nach in diese Kategorie) gar keine Rolle, und auch anderswo ist ein unsauberer Anschluss von Gebäuden zwar unschön, aber keine Katastrophe. Zumal der Ersteller des Modells das Zusammenspiel mit benachbarten Strukturen ja auch sehen wird und nachbessern kann.

Zum einen halte es nicht für realistisch, die Fähigkeiten aktueller 3D-Modeller in absehbarer Zeit in OSM umzusetzen. Man kann seit mehreren Jahren mit großen Teams entwickelte Werkzeuge nicht so leicht gleichwertig nachbauen.

Zum anderen sind das OSM-Datenformat und die regulären Editier-Werkzeuge, wozu ich etwa auch Versionsgeschichte oder Diffs rechne, nicht geeignet für den Detailgrad, den man mit einem Modelling-Tool erreichen kann. Wenn eine Information nur für die 3D-Darstellung relevant ist (z.B. die detaillierte Fototextur der einzigartigen Wandmalerei an einem historischen Gebäude, der Nachbau einer Skulptur oder die akribische Modellierung der Zierspitzen an einem Kirchendach), dann sehe ich nicht den Nutzen darin, das in der Allzweck-OSM-Datenbank abzulegen. Eher sehe ich darin die Gefahr, dass man OSM beim Bearbeiten von OSM nicht um eine eingehende Beschäftigung mit der 3D-Erfassung herum käme, obwohl viele unserer Mapper an ganz anderen Themen als 3D interessiert sind.

Mal als Beispiel: Ich hätte in OSM lieber einen artwork-Node mit ein paar übersichtlichen Attributen und einem Link auf ein 3D-Repository mit diesem Modell (nur eben in frei) als einen ohne Spezialwerkzeuge unverständlichen Haufen OSM-Nodes/Ways/Relations mit jeweils eigener History und komplexer Attributierung.

Kurz gesagt, ein Modell-Repository wäre in meinen Augen eine Bereicherung der 3D-Community und könnte gut mit anderen Ansätzen, die ja ebenfalls ihre Berechtigung haben, koexistieren.

…Ausrichtung, Maßstab und Gelände-Ansatzpunkte eines Modells zu definieren sollte doch machbar sein?..

  • natürlich ja, ich bin kein Gegner dieser Lösung, weise aber auf praktische Probleme: Auch wenn´s theoretisch einfach ist, praktisch erweißt sich das als eine Fehlerquelle-ich spreche aus der praktischen Erfahrung.
    Dazu kommt, dass in der 3D Modellierung das subjektive Empfinden des Modellierers extrem größer ist, als dies OSM gewöhnt ist. Die Stärke von OSM ist einheitliche Spezifikation und herangehensweise wodurch die Karten gut aussehen.

Ich habe einige Jahre Erfahrung mit diesem Themen, zusammen mit einer Gruppe der Mitarbeiter und ich weiß aus der Vorgeschichte dass solcher Vorschlag: frei importieren was es so gibt, schnell verworfen wurde.
Das Google solche Modelle sammelt: Wunderbar, dann sollen sie´s machen. Ich halte es für Flickwerk.

Bei der enormen Kraft und Anzahl angagierter OSM User, halte ich für sinnvoller eine Lösung aus einem Guß anzustreben, indem man zuerst in der Wiki spezifiziert, wie man solche Modelle (auch die komplizierteren) herstellt und wie man einzelne Bauteile behandelt - und anschließend loslegt.

Mein Team hat einige Tausend 3D Modelle gebaut: Sie waren ein Muster für Google, für Navteq, für Teleatlas und einige andere Firmen. Die Spezifikation darf ich der Community verschenken. Google hat eine solche Spez. immer noch nicht, daher sind deren Modelle total unterschiedlich.

Auch wenn für einen 3D Laien das Thema weniger relevant erscheint: Es ist schon wichtig zu wissen, wie man ein 3D Modell generalisiert! Wir hatten Modelle wo jemand kleine Turmdetails mit extrem vielen Polygonen gebaut hat, dafür aber Strebepfeiler vergessen. Ergebnis: Ein großes Modell, extrem schwer zu rendern und trotzdem schlecht.

Wir arbeiten mit Hochdruck an einem solchen Werkzeug für 3D Modellierung und Du bist herzlich eingeladen mitzumachen. Nächstes Arbeitstreffen ist Montag und Dienstag in Garching. :slight_smile: Nur hinweisen dass Etwas schwierig ist, bringt uns nicht weiter.

Hi Marek,

naja völlig frei von Subjektivität ist ja OSM im allgemeinen auch nicht (Zustand eines Weges etc…), was IMHO aber zur Zeit keinen gravierenden Nachteil darstellt.

Ich sehe eher ein wenig die Gefahr, dass man sehr viel Planungsarbeit in ein Vorhaben steckt, dass vlt. gar nicht so in seinem Umfang von der Community genutzt werden würde. Aber ich schätze dein Engagement in Sachen 3D wirklich sehr und es heißt ja bei einem Offenen Projekt nicht “entweder Lösung A oder B” sondern beide Lösungen können ja auf die Community losgelassen werden und sicherlich werden beide Ihre Niesche finden. Ich persönlich würde es ebend begrüßen, wenn man die Leute, die bereits konventionelles 3D Modellieren machen so für OSM begeistert kriegt. Damit das passieren kann, würde ich erstmal klein anfangen (was ich aber auch erst hier bei OSM lernen musste).

Wie gesagt leider werde ich dieses Jahr wohl leider nichts größeres anfangen können, aber vielleicht kann ich das nächstes Jahr als Projekt im Studium anrechnen lassen :slight_smile:

Liebe Leute,
ich sag´s nur so: Ich sitze in dem Thema 3D GIS seit 17 Jahren, habe meine Mitarbeiter - echte 3D Profis - 6 Monate Lang Maya, 3D Studio, Cinema und Lightvawe auf die Benutzerfreundlichkeit und Schnelligkeit der Benutzung prüfen lassen. Selbst arbeite ich schon seit 1990 mit der 3D Modelliersoftware Paketen und habe enorm viele Leute in 3D ausgebildet.
3D kann echt Spaß machen und es läßt einen genauso wenig los, wie OSM. Der Sprung von einer Welt in die andere ist etwa so, als wollte man einen Angler für Briefmarken sammeln begeistern. Beides ist ein Hobby, aber eben anders.

Ich bin überzeugt, dass eine Lösung von OSM heraus mehr Erfolg versprechend ist als “von Außen nach innen”. Es ist mir auch klar, dass kleine Schritte einfacher zu gehen sind, als große Sprünge. Ich versuche trotzdem mit einigen Verrückten eine Grundkonstruktion für die “Große” Lösung zu schaffen. Die Platzhalter werden wir dann gemeinsam füllen können. Und selbst die Grundkonstruktion ist nichts entgültiges.

Ich freue mich auf jedem Fall sehr auf Deine Zusammenarbeit nächstes Jahr.

Prinzipiell ist eine gute Lösung eine die verschiedene Wege erlaubt, daher habe ich auch Tordanik´s Ansatz bei dem 3D Meeting in Garching verteidigt. Der Weg muß ebenfalls machbar und integriert werden.

Mir fehlt bei dem ganzen Thema ein wesentlicher erster Schritt.

Es gibt ja durchaus einfache Ansätze mit building:level usw. Aber vieles ist einfach noch nicht sauber geregelt. Da wären z.B. ‘Gebäude’, die im Prinzip nur aus Dach bestehen wie Tankstellen oder überdachte Hauseingänge.

Wo es aber wirklich hakt, sind Gebäude mit unterschiedlichen Höhen/Stockwerkzahlen. Da müsste man im Prinzip mehrere ggfs. überlappende Grundflächen erzeugen. Aber wie kann man klar machen, dass diese Teile zusammen ein Gebäude bilden? Ich weis, dass es Ansätze mit z.B. Gebäude-Relationen gibt, die bisher von kaum einer Anwendung ausgewertet werden. Jedoch hat sich bisher kein Ansatz soweit durchgesetzt, dass man da mit einiger Sicherheit darauf aufbauen kann.

Zu bedenken ist, dass ein Basis-Ansatz eine generalisierte 3D-Darstellung (also ohne Feinheiten) ermöglichen soll, jedoch noch in Standard-Renderer (Mapnik, Garmin & Co.) ohne Probleme dargestellt werden muss. Insbesondere das Problem “mehrere Baukörper = ein Gebäude” sollte für Standard-Renderer befriedigend berücksichtigt werden.

Edbert (EvanE)

Hallo Edbert,
danke für absolut richtige Hinweise.

Einiges von dem, was Du schreibst hat eine Antwort, die ist aber noch nicht ordentlich aufgeschrieben:

  1. ‘Gebäude’, die im Prinzip nur aus Dach bestehen kommen in Wiki in: http://wiki.openstreetmap.org/wiki/3D_building#Canopy - inklusive Parametrisierungsvorschlag. Die Wiki Page muß ich noch komplett aufschreiben, Bilder machen,etc. aber es sind ca 2 Wochen Arbeit. Ganz ehrilch, Ich brauche Hilfe so wie Viw mir geholfen hat!

Wäre vielleicht die Münchner Runde bereit mitzuhelfen? Ich kann zu nächstem Treffen erscheinen und die Sachen schildern.
Ich habe leider ein dauerhaft krankes Kind, daher kann ich nicht so viel machen, wie ich´s gerne wollte.

  1. Gebäude mit unterschiedlichen Höhen/Stockwerkzahlen: Die Idee hierfür ist ganz einfach das Luftbild zu verwenden - also wie bisher: Die Outline die die Draufsicht umzeichnet ist Gebäude mit building:yes und bildet die Grundlage für die Dachgenerierung: Einfache Dächer nach Roof Table, komplexe nach Tordanik. Dadurch werden Mapnik, Garmin and Co. diese richtig darstellen können.
    Selbst bei einigen Bestandteilen wird der GEbäudeumriß aus der Luft also wie bisher den kleinsten gemeinsamen Nenner bilden.

Die diefferenzierte Erfassung einzelner Bestandteile sollten wir miteinander besprechen, da ist Einiges möglich. Ich werde dies in Wiki: “3D Building” als Arbeitsvorschläge platzieren.

Aber bedenke bitte, dass freie Projekte in der Regel eher nicht diese Nutzer haben :wink: und meistens Komplexität extrem gescheut wird. Aber wie du schon sagst, so oder so wird das bestimmt eine gute Bereicherung und da will ich auch auf keinen Fall etwas mies machen.

Ich würde mit meiner Lösung auch probieren gerade kleinere Objekte erfassbar zu machen (Poller, Schranken, …) nicht nur weil das beim Rendern eine enorme Detailfülle bietet, sondern weil das dann auch ein schönes Repository ist woraus andere 3D Projekte schöpfen können.

Was ich meinte war eher umgekehrt, war aber nicht explizite gesagt: Wir haben enorm viel Zeit auf der Suche nach Softwarepaketen verbracht, mit dem Ziel die Aufgabe die wir hatten: Die europäische gebaute Kulturgeschichte in 3D zu erfassen, so effizient wie möglich zu erledigen. Da ging es darum, zu vergleichen, mit welchen Kunstgriffen und Trics man die 3D Modellierung so einfach machen kann, dass die Einarbeitung leicht erlernbar und die Modellierung schnell unfd fehlerfrei wird.

Die “kleine” Lösung: Erfassung von den Elementen der Stadtmöblierung wie Poller etc. ist eine gute Sache. Stelle ein Katalog parametrisierbarer Objekte zusammen und wir werden es unter dem Begriff “3D Library elements” einsetzen.

Also unter Kleinteile verstehe ich zum Beispiel Papierkörbe Sitzbänke Litfasäulen Fahrkartenautomaten und Container für Glas/Papier/Altkleider) Wenn das bereits als 3D Textur vorliegt, wäre das genial. Einfach den Punkt eingetragen und keine weiteren Angaben. Die Automaten und Container sind eh relativ Standard. Bis auf jene die in der Erde versenkt sind und auch die Papierkörbe sollten nicht zu sehr voeinander abweichen.

Genau, und wenn man dann zum 3D Modell speichern könnte “so sieht ein Papierkorb in Stuttgart aus”, wäre das eine super Ergänzung. Da kann ich nur um Geduld bitten :wink:

In Bonn gibt es mindestens drei verbreitete Formen von Papierkörben:

  • Orange Plastik-Dinger, die an vorhanden Schilderstangen montiert sind.
  • Grüne quadratische, die direkt auf dem Boden stehen.
  • Die grünen quadratischen werden zunehmend durch
    graue runde mit senkrecht strukturierter Oberfläche ersetzt.
    Man sieht, schon bei einem simplen Papierkorb ist das nicht so einfach, wie man sich das wünscht.

Ähnlich ist es bei Pollern. Da gibt es:

  • Metall-Poller rund/quadratisch in grau oder mit rot/weißer Reflexfolie
    Höhe ca. 1 Meter Edit: Breite/Durchmesser ca. 5-10cm
  • Stein-Poller in rund/quadratisch/sechseckig,
    Höhe meist 40-50cm, Breite/Durchmesser zwischen 50 und 100cm
  • Metall-Poller, teilweise versenkbar, meist ca. 50x50x50cm
    Gängig sind die z.B. bei Minister-Vorfahrten und ähnlichem.
    Hinzu kommt noch, dass dort wo wir heute nur einen Poller als Hindernis auf einem Weg eintragen, meist mehrere stehen, für die nun ein zusätzlicher Weg eingetragen werden müsste.

Auch bei Sitzbänken, Plakatsäulen, Sammel-Container, … gibt es eine Vielzahl von Ausprägungen.

Wie so oft ist es natürlich besser eine Standard-Ausprägung für Papierkorb/Sitzbank/Automat/… zu haben als überhaupt keine 3D-Darstellung.

Edbert (EvanE)

Ich selber will mich eigentlich nicht mit 3D Modellierung beschäftigen. Mehr als building:*= und vielleicht height= ist für mich nicht drin. Aber was ich gerne machen will, ist ein Gebäude in seine einzelnen Baukörper zu gliedern, um a) den an 3D Interessierten eine Arbeitsgrundlage zu geben und b) eine einfaches 3D-Rendering zu ermöglichen.

Als Beispiel sei das Maritim Hotel in Bonn (Kurt-Georg-Kiesinger-Allee) genannt. Das besteht aus einem breiten Konferenz-Trakt im Norden mit zwei Stockwerken (Säale, Seminarräume, Empfang, Restauraunt, …) und einem schmalen, langen Zimmer-Trakt mit weiteren vier Stockwerken. Im Süden ragt der Zimmertrakt über den Konferenztrakt hinaus. Teilweise ist der Zimmer-Trakt sogar aufgeständert. Ein building:min_level=* wäre also notwendig. Die Situation kann man in Bings Vogelperspektive recht gut erkennen.

Obiges Beispiel würde ich gerne in zwei Baukörper mit unterschiedlichen building:levels gliedern, damit wenigstens eine sehr einfache 3D-Darstellung möglich ist. Allerdings soll das weiterhin ein Gebäude / eine Einheit sein, sprich beide Teile zusammen sind das Hotel Maritim.

Edbert (EvanE)