Interoperabilität für 3D-Geodaten Erfahrungen mit CityGML und OGC Web Services

Transkript

1 Interoperabilität für 3D-Geodaten Erfahrungen mit CityGML und OGC Web Services Rutger BEZEMA, Markus U. MÜLLER, Hanko RUBACH, Andreas POTH und Ugo TADDEI Dieser Beitrag wurde nach Begutachtung durch das Programmkomitee als reviewed paper angenommen. Zusammenfassung Speicherung, Verarbeitung und Visualisierung von 3D-Geodaten sind nicht erst seit der Markteinführung der virtuellen Erde des führenden Suchmaschinen-Betreibers ein wichtiges Thema in der GIS-Welt. Die Verknüpfung mit etablierten und in Entwicklung befindlichen Standards des Open Geospatial Consortium (OGC) eröffnet neue Möglichkeiten im Umgang mit 3D-Geodaten. Praktische Erfahrungen aus verschiedenen Projekten zeigen die grundsätzliche Machbarkeit, aber auch die konzeptionellen sowie technischen Herausforderungen auf dem Weg hin zu 3D-Geodateninfrastrukturen. 1 Einleitung Die Verarbeitung und Visualisierung von 3D-Geodaten ist in den vergangenen Jahren zunehmend zu einem Breitenthema geworden, was insbesondere an der Anzahl der angebotenen Lösungen, aber auch an dem großen Interesse erkennbar ist, das die Entwicklung von CityGML erfährt. CityGML ist ein GML-basiertes Austauschformat für dreidimensionale, digitale Stadtmodelle, das schon in einer Reihe von Softwareprodukten implementiert wird. Mit der Definition von CityGML und dem Einsatz von OGC Web Services (OWS) zum Zugriff auf und zur Visualisierung von 3D-Geodaten, nähern sich die Bereiche 3D- Geodatenverarbeitung und Geodateninfrastruktur einander an. Der vorliegende Beitrag basiert auf Lösungen, die unter Verwendung von Technologie aus dem deegree-projekt realisiert wurden bzw. werden, darunter: Verwaltung und Visualisierung von 3D-Stadtmodellen für Bonn, Berlin und Hamburg, Visualisierung von Digitalen Geländemodellen für das Bundesamt für Kartographie und Geodäsie, Realisierung eines transaktionalen CityGML-WFS für das Open Geospatial Consortium 1, sowie Unterstützung von Schallimmissionsmodellierung in Nordrhein-Westfalen. Die Erfahrungen aus diesen Standard-basierten Vorhaben werden diskutiert und sowohl Anforderungen als auch Chancen für den Bereich 3D-GDI in der Zukunft skizziert. 1 Im Rahmen der OGC Web Services Phase 4 Initiative.

2 76 R. Bezema, M. U. Müller, A. Poth, H. Rubach und U. Taddei 2 OGC-Standards im 3D-Umfeld Eine Reihe von Diskussionspapieren und Standards des OGC haben für 3D- Geodatenverarbeitung eine Bedeutung. Dies sind insbesondere CityGML als Datenmodellierungssprache und Austauschformat, Web Feature Service und Web Coverage Service als Datenzugriffsschicht und Web Terrain Service bzw. Web 3D Service zur Visualisierung. 2.1 City Geography Markup Language (CityGML) CityGML ist ein semantisches Objektmodell für 3D-Objekte im städtischen Raum. Es ist ein GML-Anwendungsschema, d.h. es modelliert Objekte einer Anwendungsdomäne unter Verwendung der Geography Markup Language. In dieser Hinsicht ist CityGML also sowohl ein semantisches Modell als auch ein Austauschformat. CityGML wird von der SIG 3D der Initiative Geodateninfrastruktur Nordrhein-Westfalen entwickelt, wobei anzumerken ist, dass der Mitgliederkreis dieser Arbeitsgruppe deutlich über Nordrhein-Westfalen hinausgeht. In Version 0.3 wurde CityGML dem OGC vorgestellt, und vom diesem als Discussion Paper 2 veröffentlicht (GRÖGER, KOLBE & CZER- WINSKI 2006). 2.2 Web Feature Service Ein Web Feature Service (WFS, VRETANOS 2004a) ermöglicht die Abfrage von in GML modellierten Geodaten. Zur Abfrage wird Filter Encoding (VRETANOS 2004b) benutzt, eine XML-Abfragesprache, die ähnlich SQL strukturiert ist. Ein WFS, der auch schreibenden Zugriff (Erzeugung, Änderung und Löschung) auf den Datenbestand ermöglicht wird als transaktionaler WFS (WFS-T) bezeichnet. WFS ist ein offizieller OGC-Standard mit der aktuellen Version Ein WFS in Version unterstützt GML 3.1.1, also die GML-Version, auf der auch CityGML aufbaut. Es ist somit rein konzeptionell möglich, einen WFS als lesende und schreibende Datenzugriffschicht für CityGML einzusetzen. 2.3 Web Coverage Service Ein Web Coverage Service (WCS, EVANS 2003) erlaubt den lesenden Zugriff auf alle Arten von feldbasiert modellierten Daten, also Repräsentationen von Geodaten wie Raster oder TINs. Beispiele für solche Arten von Daten sind Fernerkundungsdaten oder digitale Geländemodelle. Im Umfeld des Aufbaus von 3D-Geodateninfrastrukturen kann über einen WCS beispielsweise auf Geländedaten im Rasterformat zugegriffen werden. WCS ist ein aktueller OGC-Standard mit der derzeitigen Versionsnummer Web Terrain Service Ein Web Terrain Service (WTS), im discussion paper Status vom OGC, generiert Ansichten von 3D-Szenen, d.h. im Gegensatz zur zweidimensionalen Darstellung eines WMS, 2 Ein OGC Discussion Paper hat nicht den Status eines OGC-Standards. Es wird nur vom OGC als potenziell interessante und somit diskussionswürdige Technologie anerkannt.

3 Interoperabilität für 3D-Geodaten 77 wird hier eine dreidimensionale Darstellung generiert. Voraussetzung ist natürlich, dass entsprechende 3D-Daten zur Verfügung stehen. Die Entwicklung der WTS-Spezifikation geht etwas schleppend voran, so dass bislang noch kein verabschiedeter Standard vorliegt. Die aktuellste Entwurfsversion trägt den Namen Web Perspective View Service, um zum Ausdruck zu bringen, dass es mit diesem Service nicht nur möglich ist Gelände darzustellen. Abb. 1: Visualisierung von Gelände und Gebäuden mit deegree WTS/WPVS In Abbildung 1 wird das Ergebnis eines GetView-Aufrufes and einen WTS/WPVS gezeigt. Hierbei wurde ein digitales Höhenmodell, auf das Luftbilder als Geländetexturen gelegt wurden sowie Gebäudemodelle als Datengrundlage benutzt. Der Web Perspective View Service (WPVS) präsentiert Information zu 3D-Objekten. Die wichtigste Operation dabei ist GetView, die statische Bilder einer 3D-Landschaft darstellt. Die GetView-Operation kann man als Erweiterung einer WMS GetMap-Operation verstehen, welche durch Parameter erweitert wird, die die drei-dimensionale Darstellung ermöglicht. Zu diesen Parametern zählen die Rotation und die saisonal bedingte Beleuchtung der Landschaft und der 3D-Objekte (Gebäude). Da das Ergebnis einer GetView-Anfrage ein Bild ist, ist die direkte Interaktion mit der 3D-Ansicht zunächst nicht möglich. Ein WPVS- Client ist daher vergleichsweise nicht sehr interaktiv; auf der anderen Seite erkennt man dies als Vorteil für eine browserbasierte Anwendung. Ein entsprechender Client benötigt keine Browser-Erweiterungen und ist daher vergleichsweise schlank. Zudem ist ein WPVS- Client leicht in andere Portale zu integrieren, die beispielsweise auf WMS-Technologie aufbauen.

4 78 R. Bezema, M. U. Müller, A. Poth, H. Rubach und U. Taddei Die Herausforderung, einen WPVS-Client zu entwickeln besteht nun darin, die Komplexität einer GetView-Anfrage hinter einer ansprechenden und intuitiv zu bedienenden graphischen Benutzerschnittstelle (kurz GUI) zu verstecken. Diese GUI ermöglicht dann die Navigation im 3D-Raum. 2.5 Web 3D Service Ein Web 3D Service (W3DS, QUADT & KOLBE 2005) erfüllt letztendlich die gleiche Aufgabe wie ein WTS bzw. WPVS: er ermöglicht die Visualisierung von 3D-Geodaten. Der Unterschied besteht allerdings darin, dass ein WTS Bilder liefert, während ein W3DS Szenengraphen, die beispielsweise in VRML repräsentiert sind, abgibt. W3DS ist bislang ein sog. OGC discussion paper. Es ist abzusehen, dass die beiden Ansätze für 3D-Visualisierungsdienste in absehbarer Zukunft harmonisiert werden. Interessant dürfte hierbei sein, dass es Bestrebungen gibt, die Keyhole Markup Language (KML) im OGC zu standardisieren. Es ist zu erwarten, dass dies auch Auswirkungen auf den W3DS haben wird. 3 Anwendungsfälle In den in der Einleitung genannten Projekten werden die folgenden Anwendungsfälle unterstützt. 3.1 Verwaltung von Digitalen Stadtmodellen Digitale Stadtmodelle werden oftmals mit CAD-Systemen erzeugt und in CAD-Formaten dateibasiert abgelegt. Dies hat eine Reihe von Nachteilen zur Folge. So ist es beispielsweise nicht möglich, auf strukturierten Wegen Teile der Stadtmodelle zu selektieren oder die Fortführung zu organisieren. Aus diesem Grund haben Institutionen, die solche Stadtmodelle pflegen den Bedarf eines einheitlichen, möglichst Datenbank-gestützten Datenbestandes. Zur Erfüllung diesen Anwendungsfalles ist es notwendig, CityGML in einer meist relationalen Datenbank zu speichern. Hierbei ist es in Bezug auf verteilte Nutzer in einer heterogenen System- und Netzinfrastruktur sinnvoll, einen WFS zum Lesen als auch zum Schreiben der Daten einzusetzen. Mittels des WFS können dann Datenbestände mit Hilfe von fachlichen und geometrischen Anfragen selektiert werden. Um den gesicherten Zugriff (also Zugriff auf Basis definierter Berechtigungen) zu ermöglichen, ist es notwendig, das WFS-Protokoll um Zusätze zu erweitern, wie sie beispielsweise im Rahmen von GDI NRW als Access Control Services entwickelt und ebenfalls in den OGC-Prozess eingebracht wurden. Eine entsprechende Implementierung im deegree- Projekt (igeosecurity) liegt vor und kommt in den Projekten zum Einsatz. 3.2 Web-Visualisierung Der Mehrwert von 3D-Geodaten liegt unter anderem in den Möglichkeiten ihrer Visualisierungen. Grundlegende Anwendungsfälle sind hierbei die Unterstützung von Planungspro-

5 Interoperabilität für 3D-Geodaten 79 zessen, die Navigation und die Unterstützung von Vertriebsmöglichkeiten. Im Rahmen von Planungsprozessen ist mit 3D-Geovisualisierungen möglich, die Konsequenzen von städtebaulichen Maßnahmen anhand einer entsprechenden Visualisierung schon durchzuspielen, bevor eine Umsetzung erfolgt. So können Sichtbarkeitsanalysen oder auch die rein visuelle Wirkung einer städtebaulichen Maßnahme überprüft werden. Im touristischen Bereich, zu dem hier auch Stadtpläne im Internet gezählt werden, kann durch 3D-Visualisierungen der Erkennungswert von bestimmten Sehenswürdigkeiten aber auch allgemein einer Route stark verbessert werden. Großes Potenzial entsteht hierbei in der Kopplung von 2D- (Karten)-darstellungen mit 3D-Szenenvisualisierungen. Oftmals werden 3D-Visualisierungen sowohl von Gelände- als auch Gebäudemodellen zur Verfügung gestellt, um den Vertrieb der zugrundeliegenden Daten zu unterstützen. Die ansprechende Darstellung der 3D-Daten verfolgt hierbei das Ziel den potenziellen Kunden auf die Möglichkeiten der Daten hinzuweisen. 3.3 Umgebungslärm Die EU-Richtlinie 2002/49/EG über die Bewertung und Bekämpfung von Umgebungslärm ( Umgebungslärmrichtlinie ) verpflichtet die Mitgliedstaaten, in einem mehrstufigen Verfahren Schallimmisionspläne und Aktionspläne zu erstellen sowie die Öffentlichkeit über die Umweltbelastung durch Schallimmision zu informieren (EUROPÄISCHE UNION 2002). Für die Berechnung von Schallimmissionsplänen (FITZKE 1996) wird eine Vielzahl von Geoinformationsressourcen benötigt, die überdies in dreidimensionaler Ausprägung vorliegen müssen, insbesondere: Geländemodell Gebäudemodell mit Einwohnerdaten Straßenmodell mit Verkehrsdaten Schienenmodell mit Verkehrsdaten Lärmschutzbauten In Nordrhein-Westfalen werden die entsprechenden Prozesse der Datenbearbeitung und -bereitstellung mit GDI-Komponenten realisiert (STÖCKER-MEIER et al. 2007). Das digitale Geländemodell wird über einen deegree Web Coverage Service, die übrigen Daten über Web Feature Services bereitgestellt. Dabei werden die der eigentlichen Schallimmisionsberechnung vorgelagerten Datenaufbereitungsprozesse durch einen transaktionalen deegree Web Feature Service unterstützt, beispielsweise die Ergänzung der Gebäude um Angaben zu Einwohnern und Fassadeneigenschaften, Verfeinerung des Geländemodells durch Bruchkanten etc., Ergänzung von vorhandenen Lärmschutzwänden. Die bisherigen Erfahrungen mit dem Web Coverage Service sind ohne Einschränkungen gut. Das in 10 m horizontaler Auflösung vorliegende DGM5 des Landesvermessungsamtes wird in beliebiger Auflösung performant als GeoTiff oder XYZ-kodierte ASCII-Daten ausgeliefert. Für die Web Feature Services steht der Eignungsnachweis noch aus. Insbesondere wird erst der Produktionsbetrieb unter Nutzung des vollständigen Gebäudemodells für die Umgebungslärmkartierung (ca. 6,4 Mio. ALK-Gebäude) zeigen, ob die Auslegung der 3D- Datenbank unter Oracle und des Applikationsservers für den WFS den Performanzansprüchen genügen werden allein die Befüllung der Datenbank hat bereits über 30 Tage in Anspruch genommen.

6 80 R. Bezema, M. U. Müller, A. Poth, H. Rubach und U. Taddei 4 Technologische Herausforderungen Die Speicherung, Verarbeitung, Analyse und Visualisierung von 3D-Geodaten stellt eine Reihe von Herausforderungen sowohl allgemeiner Natur als auch im OGC-Umfeld. Diese werden im Folgenden diskutiert. 4.1 Performanter Zugriff auf große Mengen von Rasterdaten Digitale Geländemodelle zeichnen sich durch große Datenmengen und meist durch einen inhomogenen Erfassungszeitraum aus. Dieser resultiert aus der Tatsache, dass Geländedaten selten vollständig für ein gesamtes Gebiet erhoben, sondern in Teilschritten erzeugt und aktualisiert werden. Meist werden Geländedaten in einer großen Menge von Dateien verwaltet, so dass der performante Zugriff nur mit Hilfe einer räumlichen Indizierung möglich ist. Im deegree WCS wird dazu ein Quadtree-Index genutzt, bei dem jede Datei über die räumlich Ausdehnung der enthaltenen Daten im Quadtree abgelegt wird. Um die Datenmenge, die bei der Visualisierung angefragt werden muss, einzugrenzen, wird zudem eine Auflösungspyramide eingesetzt, so dass beim Zugriff die Menge an Daten stark eingeschränkt ist. Eine weitere Anforderung besteht darin, dass die Höhendaten in Teilen aktualisierbar sein müssen, was zur Folge hat, dass bei einer Aktualisierung die entsprechenden Indizierungen ebenfalls aktualisiert und die Pyramide teilweise neu berechnet werden muss. 4.2 Speicherung und Abfrage von CityGML mit Hilfe relationaler Datenbanken Die Abbildung von CityGML-Konstrukten auf relationale Datenbanken birgt eine Reihe von konzeptionellen und technischen Herausforderungen. Objekte, wie sie in GML definiert werden, sind nicht direkt auf relationale Datenbanken abbildbar. Dies ist ein in der Informatik seit langem bekanntes Problem, für das es eine Reihe von Lösungsansätzen gibt. Die Abbildung geometrischer Konstrukte in Datenbanken ist in einer Reihe von DBMS gelöst, so dass hier auf vorhandene Lösungen zurückgegriffen werden kann. Dies ist allerdings bislang fast ausschließlich auf 2D- bzw. 2.5D-Daten beschränkt, so dass hierdurch ein weiteres Problem entsteht. Zudem ist auch hier die Frage nach der Performanz zu beantworten, da eine Reihe von möglichen Abbildungen zwischen CityGML und relationaler Datenbank möglich sind, aber nur ein Teil dieser Lösungen sowohl beim lesenden als auch schreibenden Zugriff performant funktioniert. Das deegree-projekt setzt hier auf den Zugriff über einen transaktionalen WFS. Dieser wird direkt durch GML-Anwendungschemata konfiguriert, die über Erweiterungen Informationen zur Abbildung in der Datenbank enthalten. Beim Datenbankdesign wurde von den CityGML-Konstrukten abstrahiert, d.h. die CityGML-Objekte wurden nicht 1:1 in der Datenbank umgesetzt. Die Datenbank ist somit flexibler hinsichtlich Erweiterungen und Versionsanpassungen, aber auch erheblich performanter. 4.3 Qualität und Performanz bei der Visualisierung Nicht nur bei der Speicherung von und dem Zugriff auf Geodaten sind Optimierungen von großer Bedeutung. Auch bei der Visualisierung der Daten spielt die Abwägung zwischen

7 Interoperabilität für 3D-Geodaten 81 Qualität der Darstellung und Performanz eine wichtige Rolle, vor allem wenn es sich um eine Darstellung handelt, die über das Web angefordert wird. Es ist nahezu ausgeschlossen, die zum Teil extrem großen Datenmengen verschiedener Datenquellen in höchster Auflösung über eine Leitung zu schicken, weshalb beim deegree-wpvs verschiedene Optimierung serverseitig durchgeführt werden. Diese Optimierungen werden im Folgenden kurz vorgestellt. Eine erste Optimierung findet beim Abschneiden der Ansicht statt, auch culling genannt. Es ist leicht einzusehen, dass nur die Daten angefordert werden müssen, die von einem Betrachter tatsächlich gesehen werden können. Zu diesem Zweck wird zuerst das so genannte View Frustum berechnet; es beschreibt den für den Benutzer sichtbaren Raum. In der 3D-Computer-Graphik hat dieses Frustum eine Pyramidenform. Bei der Visualisierung von Geodaten wird dieses Frustum jedoch auf eine Ebene projiziert, was in einem gleichschenkligen Trapez resultiert, in dem die Basis dem Betrachter zu gewandt ist (WATT 2000). Ein weiterer Optimierungsschritt besteht nun darin, das Trapez in verschiedenen Auflösungsstufen, in Abhängigkeit der Entfernung zum Betrachter, zu unterteilen und somit die Größe der abzufragenden Datenmengen zu reduzieren. Dies entspricht einer Level-of- Detail-Strategie wobei die feinste (detaillierteste) Anfrageauflösung sich nahe dem Betrachter befindet. Eine neue Auflösungsstufe wird dann erreicht, wenn sich die Länge der Basis innerhalb des Trapezes verdoppelt. Am Ende dieses Optimierungsschrittes stehen somit eine Menge Anfragetrapeze zu Verfügung die das projizierte Frustum optimal annähert. Die Anfragetrapeze stellen also ein optimales Trade-off zwischen Datenmenge und Qualität dar. Leider ist es jedoch mit ihnen nicht möglich, Datenquellen direkt anzusprechen, die mit einer Rasterdaten-Schnittstelle arbeiten, wie es bei WMS und WCS der Fall ist. Sie können nur Anfragebereiche bearbeiten, die an den Achsen des zugrunde liegenden Koordinatensystem ausgerichtet sein. Zum Ansprechen dieser Services, ist es daher nötig, die Trapeze in optimale achsenausgelegte Anfragen zu unterteilen. Eine Möglichkeit diese Unterteilung zu erstellen, ist die Benutzung eines Quadtrees, wie es beispielsweise der deegree-wpvs realisiert. Ein Quadtree ist eine aus der Informatik bekannte Datenstruktur, die bei ihrer Erstellung eine geometrische Menge solange aufteilt, bis ein bestimmtes Terminierungskriterium erfüllt ist. Der resultierende Baum ist eine effektive Repräsentation der räumlichen Daten, in der zusammengehörende Geometrien performant gesucht werden können. Somit lassen sich die achsenausgelegten Geometrien zusammenfügen, die in einer Auflösungsstufe liegen. Ein weiterer Vorteil der Erstellung von Auflösungsstufen ist die Möglichkeit, die Daten pro Auflösungsstufe in einem separaten Progammzweig ( thread ) zu erzeugen so, dass die entstehende Prozesslast auf aktuellen Multi-Prozessoren gut aufgeteilt werden kann, was ein performantes Aufbauen der 3D-Szene ermöglicht. 4.4 Konzeptionelle Probleme zwischen GDI/GIS und CAD In den meisten Fällen werden digitale Gebäudemodelle durch CAD-Systeme erzeugt, die von ihrem Entwurf her anderen Konzepten als GIS gehorchen. Diese Unterschiede äußern sich beispielsweise in der Objektbildung und der Vergabe von eindeutigen Identifikatoren.

8 82 R. Bezema, M. U. Müller, A. Poth, H. Rubach und U. Taddei Hier sind teilweise Umgehungen zu implementieren, um die Probleme zu lösen. Es lässt sich allerdings feststellen, dass unterschiedliche CAD-Systeme unterschiedliche Möglichkeiten bieten. So war es im Rahmen einer Zusammenarbeit mit der Firma CLiB GmbH möglich das System Microstation so zu erweitern, dass es in der Lage ist eine CityGML- Ausgabe zu erzeugen, die direkt für deegree WFS-Transaktionen verwendet werden konnte und so und die 3D-Datenbank einzuspielen sind. 5 Architektur eines Lösungsansatzes Im Folgenden wird eine Architektur beschrieben, die mit Hilfe des deegree-frameworks in einer Reihe von Projekten zum Einsatz kommt. Abb. 2: Architektur einer 3D-GDI In Abbildung 2 wird exemplarisch die Architektur einer 3D-GDI dargestellt, die in den beschriebenen Projekten mit Hilfe von deegree-komponenten umgesetzt wurde. Die Speicherung der Gebäudemodelle erfolgt in einer Geodatenbank, beispielsweise in PostGIS oder Oracle Spatial. Ein transaktionaler WFS (WFS-T) stellt den lesenden und schreibenden Zugriff auf diesen Datenbestand zur Verfügung. Um Kontrolle über den Datenfluss zu gewährleisten, wird der WFS durch einen owsproxy abgeschirmt. Die Bearbeitungskomponente dies ist oftmals ein CAD-System greift auf den Datenbestand über owsproxy und WFS zu. Geländedaten können ebenfalls in der Geodatenbank gespeichert werden, dies bietet sich insbesondere an, wenn keine Rasterdaten, sondern TINs oder Massenpunkte genutzt werden. Alternativ können Rasterdaten auch in Dateiformaten gespeichert werden, wobei hier die beschriebenen Mechanismen zum performanten Zugriff auf diese Daten eingesetzt werden müssen. Der Zugriff auf die Geländedaten im Rasterformat erfolgt über einen WCS.

9 Interoperabilität für 3D-Geodaten 83 Bei der Ausleitung von Szenen des Stadtmodells kann somit auf einfache Art und Weise das dazu passende Stück Gelände mit ausgegeben werden. Auf der rechten Seite von Abbildung 2 wird dargestellt, wie die Visualisierung erfolgt. deegree-wpvs greift hierbei die in der Geodatenbank gespeicherten Daten zu. Alternativ ist es möglich, dass externe WFS- oder WCS-Dienste eingebunden werden. Neben den 3D- Daten werden noch Texturen für das Gelände benötigt, beispielsweise Luftbilder, und Karten zur Orientierung. Diese Daten können über einen WMS eingebunden werden, in den Projekten ist dies deegree WMS oder eine beliebiger andere Software, die die WMS- Schnittstelle implementiert. Ein webbasierter WPVS-Client stellt eine Benutzerschnittstelle zur Verfügung, die über gängige Browser benutzt werden kann. 6 Zusammenfassung und Ausblick Die Entwicklung von CityGML und WFS definieren wichtige Schritte hin zur Entwicklung von 3D-Geodateninfrastrukturen. Die gemachten Erfahrungen in verschiedenen Projekten sind ermutigend, sie zeigen, dass es derzeitig schon möglich ist, eine 3D-GDI zum produktiven Einsatz zu bringen. Wichtig für die Zukunft erscheint vor allem, dass die Spezifikationen WPVS und CityGML zu einem ersten Abschluss gebracht und vom OGC verabschiedet werden. Hinsichtlich CityGML ist ebenfalls offen, wie Darstellungsvorschriften definiert werden, hier erscheint der Einsatz von Symbology Encoding (MÜLLER 2006) sinnvoll. Daneben sollte die WPVS- Spezifikation um die Möglichkeit erweitert werden, parallel zur GetFeatureInfo-Operation des WMS, Objektinformationen abzufragen. Literatur Europäische Union (2002): Richtlinie 2002/49/EG des europäischen Parlaments und des Rates vom 25. Juni 2002 über die Bewertung und Bekämpfung von Umgebungslärm. EVANS, J. (2003): Web Coverage Service (WCS) Version OpenGIS Project Document R6. FITZKE, J. (1996): GIS-gestützte Berechnung von Schallimmissionen, in: Proceedings Informatik '96, Klagenfurt, September GRÖGER, G., T. KOLBE & A. CZERWINSKI (2006): City Geography Markup Language. OGC project document r1. HAMMES, J. (2001): Modeling of ecosystems as a data source for real-time terrain Rendering, In: Digital Earth Moving : First International Symposium, DEM 2001, Manno, Switzerland, September 5-7, 2001, Proceedings, S. 98 ff. MÜLLER, M. (2006)(Hrsg.): Symbology Encoding Implementation Specification. OGC project document r4.

10 84 R. Bezema, M. U. Müller, A. Poth, H. Rubach und U. Taddei PENDERGAST, M. (2003): Navigate through virtual worlds using Java 3D. JavaWorld.com; 07/04/03; THIEMANN, F. (2003): 3D-Gebäude-Generalisierung, in: Kartographische Schriften, Band 7, Visualisierung und Erschließung von Geodaten, Seminar GeoVIS 2003, Februar 2003, Hannover, S VRETANOS, P.A. (2004a). OpenGIS Web Feature Service Implementation Specification Version OpenGIS Project Document VRETANOS, P.A. (2004b). OpenGIS Filter Encoding Specification Version Open- GIS Project Document STÖCKER-MEIER, E. et al. (2007): Umsetzung der Umgebungslärmrichtlinie aus der Sicht des Landes Nordrhein-Westfalen, In: Lärmbekämpfung Zeitschrift für Akustik, Schallschutz und Schwingungstechnik, Bd.2. Jg. 2007, Heft Nr. 1, S QUADT, U. & T. KOLBE (2005): Web 3D Service. OGC project document WATT, A. (2000): 3D computer graphics( third edition). Internetverweis