Andreas Voigt - Der Blog!

So, nachdem der Stress der letzten Tage (Meeting mit dem Landesvermessungsamt, Veranstaltung am DFKI) vorüber sind, kann ich mich auch wieder einmal einem neuen Blog-Eintrag widmen.

Um noch einige Sachen aufzufrischen, muss ich diesmal ein klein wenig weiter ausholen:

Der Mapserver, an dem ich zur Zeit arbeite, soll von der Grundfunktionalität ähnlich zu einem "normalen" WMS sein. Die Ausgabe erfolgt also hauptsächlich in Form von Kacheln unterschiedlicher Detailstufe (LOD). Diese Kacheln werden dann wie bei Google Maps auf Browserseite zu einem Gesamtbild oder besser einem Gesamtobjekt zusammengesetzt. So zumindest ist es geplant. Bisher habe ich mich immer mit einer Kachel beschäftigt und versucht diese zu vervollständigen und die dazu gehörigen Objekte in möglichst guter Qualität zu generieren. Bisher handelt es sich dabei um Straßen, Straßenlampen und neuerdings auch Flächen. Die Geländeflächen sind allerdings noch nicht ganz komplett. Zur Zeit wird hier nur das Randpolygon trianguliert. Die inneren Punkte sind bereits vorhanden und müssen "nur" noch in die Vernetzung mit einbezogen werden.

Dies ist also ein riesen Schritt vorwärts und da es nun auch erstmals keine Screens gibt, die ich aufgrund mangelnder Grafik-Qualität zurückhalten will, gibt es dieses Mal (wie ja auch versprochen) neues Anschauungsmaterial.

Wie bereits angesprochen sind hier die ersten Geländeflächen zu sehen (dunkel-violett). Hierbei handelt es sich um Flächen mit besonderer Nutzungsart, z.B. Regierungsgelände, Ministerien,... Auf dem letzten Bild sind zudem senkrecht verlaufende Straßen zu sehen. Dies hat keine größere Bedeutung, als das dort schlicht die Geländeinformationen (das DEM) zu Ende sind.

Als nächstes werden nun die inneren Punkte der Geländeflächen mit in die Vernetzung einbezogen (nächste Woche), sowie, falls vorhanden, erste Gebäude einfach visualisiert. Damit wären dann die Grundbestandteile soweit vorhanden. Weiterhin wird demnächst Zeit in eine sinnvolle GUI investiert werden müssen. Dort sollen dann die einzelnen Kachel zusammengefügt sowie unterschiedliche Layer an und ausgeblendet werden können.

In dieser Woche ist wieder reichlich passiert vor allem in Hinblick auf das Straßennetz, das visualisiert werden soll. Abgesehen von einer umfangreichen Änderung der Mapserver-Architektur gibt es ein paar Verbesserungen bei den Kreuzungsbereichen und an den Straßen an sich. Dazu gehört die Einbeziehung von Höhendaten. Aber auch neue Schwierigkeiten sind aufgetreten.

Mapserver-Architektur

Am Mapserver hat sich in sofern etwas geändert, dass es nun nicht mehr alleine eine Methode gibt, welche für das Rendern der Geo-Daten zuständig ist, sondern es wurden nun Geo-Objekte eingeführt, die für ihr eigenes Rendering zuständig sind. Um es einmal umgangsspachlich auszudrücken: "Eine Straße weiß noch am besten, wie sie aussehen muss." Diese Änderung macht das Anpassen der Rendering-Prozeduren unkomplizierter und ermöglicht hoffentlich eine leichtere Erweiterung. Außerdem ist damit eine Straße auch wirklich eine Straße mit all ihren Eigenschaften (Fahrbahnbreite, Anzahl der Fahrspuren, etc...) und nicht nur ein Eintrag von Geometrieknoten in einem Vektor.

Verbesserungen im Straßennetzwerk

Wie ja bereits angesprochen, wurden einige Verbesserungen im Straßennetzwerk durchgeführt. Dazu gehört zum Einen die Einbindung von Höhendaten aus einem Laserscann-Datensatz mit einer Auflösung von 1m. Datensätze dieser Auflösung sind nicht frei erhältlich und müssen in der Regel teuer bezahlt werden. Frei Nutzbar sind die SRTM-Daten der Nasa. Allerdings ist ihre Auflösung zur Zeit auf 90m (weltweit) beschränkt. Allein die Höhendaten sorgen bereits für eine enorme optische Aufwertung. Zusätzlich wurde die Anzahl der Geometrieknoten der Straße erhöht. Dies führt nicht immer zu sofort sichtbaren Verbesserungen, soll jedoch einmal noch weitere Vorteile mit sich bringen. An diese Knoten könnten beispielsweise Straßenlaternen, Leitplanken und ähnliches gekoppelt werden. An den Straßenlampen arbeite ich zur Zeit, auch dies wird optisch noch einmal sehr viel verbessern. Mit den Straßenlampen wäre dann auch ein Tag-Nacht-Wechsel denkbar. Vor allem die Nachtszenen mit der Beleuchtung könnten dann durch das Raytracing sehr tolle optische Ergebnisse liefern. (Gleich mal merken für nächste Woche. ^^)

Geplant sind auch noch Fuß- und Radwege, die ich aber auf Grund von fehlenden Einträgen in den GIS-Daten noch nicht in Angriff genommen habe.

Die GIS-Daten könnten jedoch ein größeres Problem verursachen: Sie erfordern eine hohe Stellengenauigkeit. Float-Werte mit 7-8 Stellen sind dort bei weitem nicht mehr ausreichend. Eine typische Gauß-Krüger-Koordinate besitzt alleine 7 Stellen vor dem Komma. Da es eine Meter-Angabe ist werden bestimmt noch weitere 3 bis 4 Stellen hinter dem Komma benötigt, um Geometriefehler zu vermeiden. Dies gibt das XML3D leider derzeit nicht her. Ich werde mich dort auch noch mal mit den Entwicklern zusammen setzen müssen und an einer Lösung arbeiten. Eine Erhöhung der Präzision ist (double) ist nicht so einfach zu implementieren, denke ich, außerdem verdoppelt dies den Speicheraufwand. Bei sehr großen Modellen (typisch für GIS) ist allerdings dort auch sehr schnell der verfügbare Speicher von etwa 1,4 GB (32bit) aufgebraucht. Am besten wäre der Umstieg auf 64bit und Einführung der double-Präzision...

Zu tun ist also noch:

- Aufbereitung der Fahrbahnmarkierungen

- Straßenlampen

- Gehwege

- Gelände

Coming Up: Siehe Coming Up vom letzen Beitrag! ^__^

So, wieder ist recht viel Zeit vergangen seit dem letzten Eintrag in den Blog bzw. dem letzten Bericht über das XML3D.

Heute werde ich einen Zwischenbericht über den aktuellen Stand, Hindernisse und ähnliches geben. Ob es ein bisschen Anschauungsmaterial geben wird, werde ich mir im Laufe dieses Beitrags überlegen.

Ok, wodran bastel ich konkret? - Es gibt momentan 2 Projekte an denen ich Arbeite:

3D-WebGIS-Prototyp

Dies ist mein Hauptprojekt und damit auch meine Diplomarbeit

Ähnlich wie bei Google Maps oder OpenStreetMap teilt sich dieser Prototyp in mehrere Teile auf. Zum Einen ist dies ein Mapserver, der für das Erstellen der Geometrie aus GIS-Daten verantwortlich ist. Der Mapserver liefert als Ausgabe dann Kacheln mit einer oder mehreren Objektarten. Zum anderen ist für eine sinnvolle Betrachtung und Steuerung eine GUI notwendig. Diese soll auch über erste GIS-Funkionalitäten verfügen - abfragen von Objektdaten.

Der Mapserver ist momentan mein Hauptaugenmerk und auch der umfangreichste Teil der gesamten Arbeit. Für den 2D-Fall gibt es bereits mehrere verschiedene Mapserver, wobei der am weitesten verbreitete wohl der UMN MapServer sein wird. Dieser arbeitet OGC-konform, also nach Standards des Open Geospacial Consortium. Die OGC-Standards und damit auch der MapServer sind zur Zeit allerdings nur für die Verarbeitung von 2D-Geodaten und hauptsächlich für die Ausgabe als Bild ausgelegt. Eine Umarbeitung auf ein 2,5D oder 3D-Format ist extrem schwierig - auch durch die komplizierte Struktur des MapServers. Daher habe ich begonnen Eigenentwicklung eines XML3D-Mapservers zu schreiben. Wie der Name bereits sagt wird er vor allem für das XML3D-Format ausgelegt sein. Die Ausgabe von "gerenderten" 3D-Geodaten erwies sich in den letzten Wochen aber als schwieriger als ursprünglich erwartet. Um einen kurzen Vergleich zu bekommen, erläutere ich einmal kurz wie etwa ein 2D-Mapserver das macht: Der 2D-Mapserver arbeitet natürlich auch mit "normalen" Geodaten - also Punkten, Linien und Flächen (Vektordaten). Diese Vektordaten bzw. ausgewählte Teile davon werden in einen Arbeitsraum projiziert. Dieser Arbeitsraum entspricht einer Grafik von 256x256 Pixeln. Dort werden dann die Pfad-ähnlichen Vektoren ähnlich wie die Pfade in Photoshop mit unterschiedlichen Pinseln gerendert. Oft wird dies auch von speziellen Rendering-Clients übernommen.

In dem 3D-Fall geht dies leider nicht mehr so einfach. Es gibt einige Versuche (auch von OpenStreetMap: OSM-3D), die die 2D-Ausgabe nutzen und auf ein digitales Höhenmodell (DHM od. DGM od. DEM) mappen. Leider hat das zur Folge, dass Flüsse schon mal bergauf fließen oder Straßen an einem Steilen hang schräg verlaufen... Ich versuche mich mit meiner Diplomarbeit an einem anderen Ansatz um diese Erscheinungen zu verhindern. Jede Geometrie soll dort als richtige 3D-Geometrie und nicht nur als Textur verfügbar sein. Das was der Mapserver also machen soll ist aus den Geometrien, die als Punkte, Linien und Polygone in einer Datenbank abgespeichert sind, prozedural Geometrien generieren. Ein Straßenstück prozedural zu erzeugen ist noch einfach, mehrere Straßenstücke prozedural zu generieren ist unter bestimmten Bedingungen auch noch einfach. Aber wie ist dies beispielsweise mit Kreuzungen? Kreuzungen sind komplexe Gebilde, die aus einem Kreuzungsbereich bestehen, welcher je nach Straßenbreite, anliegender Bürgersteig, Schnittwinkel, usw. ganz unterschiedliche Ausmaße und Formen annehmen kann. Die Knotenpunkte dafür zu generieren ist eine Sache, diese vernünftig zu vernetzen und auch eine entsprechende Textur darauf zu legen ist eine andere.

Ähnlich, aber nicht so arg kompliziert ist die Generierung von Knotenpunkten von Straßen - dort muss möglicherweise Kurvenstücke erzeugt werden. Es muss beachtet werden, ob sich die Anzahl der Spuren oder die Fahrbahnbreite verändert hat und dazu dann eine entsprechende Geometrie mit Textur erzeugt werden. Da derzeit noch keine Höhenwerte direkt in den GIS-Daten vorhanden sind, soll ein DEM zur Hilfe genommen werden.

Abgesehen von Liniendaten muss noch ein Gelände aus Flächendaten unter Einbeziehung des DEMs erzeugt werden. Auch haben wieder die Vernetzung und die Texturierung den größten Schwierigkeitsgrad.

Ist dies geschafft sollte hoffentlich eine geschlossene Oberfläche ohne Z-fighting-Effekte existieren. Z-fighting tritt auf, wenn sich mehrere Fläche überlappen bzw. ineinander liegen. Aufgrund von numerischen Ungenauigkeiten (Rundungsfehler ^^) oder Einstränkungen durch den z-Buffer entsteht ein recht hässliches Flackern, bei dem gleichzeitig Teile der einen und Teile der anderen Fläche sichtbar sind. Selbst eine Erhöhung der Präzision wird dort nicht unbegrent Abhilfe schaffen können.

Linien und Flächen sind aber immer noch nicht alles - übrig bleiben Punktdaten, die zum Beispiel wie bei Bäumen oder Pollern durch instanziierte Objekte visualisiert werden können. Dies sollte keine große Schwierigkeit darstellen.

Das zweite Projekt werde ich nur kurz erwähnen: Es handelt ich dabei um ein Terminal, welches in einem Museum ausgestellt werden soll. Dort wird es eine recht große XML3D-Szene zu sehen geben, durch die man sich frei bewegen können soll. Es wird POIs (Points of Interest), eine Übersicht, geführte Touren und natürlich jede Menge Informationen geben. Das ganze wird dann per Touch-Display gesteuert und sowohl auf dem Touch-Display, als auch auf einer großen Leinwand in Stereo wiedergegeben (so zumindest der Plan). Man kann sich also davor stellen und sich die Szene in 3D ansehen.

An dieser Stelle mache ich nun ersteinmal wieder Schluss.

Coming Up: Eine hübsche Ausgabe vom Mapserver (hoffentlich ^^")

Einige Zeit ist bereits wieder vergangen und auch einiges hat sich getan.

Bevor ich aber zu Neuigkeiten komme möchte ich noch schnell zu Ende führen, was ich im Juni angefangen habe.

Die in "Straße Teil 1" dargestellte Szene wurde im Nachhinein erweitert. Dort ist nun nich mehr ein Straßenstück enthalten, sondern ein gesamter Straßenzug, der sich aus vielen einzelnen Stücken zusammensetzt. Da das Element aus Teil 1 bereits automatisch aus definierten Punkten generiert wurde, war es nun nicht mehr schwer weitere Straßenelemte hinzuzufügen und einen vollständigen Zug daraus zu machen.