Interoperable Integration of 3D Models over the Internet for Emergency Preparedness and Response

By Dr. Thomas H. Kolbe

Disaster management and homeland security planning require ad-hoc access to and integration of different types of geoinformation from different sources.International standards of the Open Geospatial Consortium (OGC) and the International Organization for Standardization (ISO) are widely seen as the key for building interoperable and system independent spatial data infrastructures (SDI) (see Marian de Vries' article). In fact, standards for two-dimensional geodata, like maps, aerial and satellite imagery, and vector data describing topography, cadastre, and different types of networks have been established over the last five years.

However, many applications in disaster management also need information about terrain height, water levels, and affected objects like buildings and installations.Therefore, virtual 3D city models constitute an important source for 3D geoinformation for emergency preparation and response.In particular they:
  1. Document the shape and configuration of a city. In case of destruction of infrastructure, immediate access to these reference data allows quick assessment of the damage, helps responders, and last but not least, can be helpful in rebuilding sites.
  2. Enable visualizations.Augmented reality systems can provide responders with information that is visually overlaid with their view of the real world.Such systems need 3D city models in order to compute the positions and occlusions of the overlay graphics.
  3. Allow the development of escape routes inside and outside of buildings.
  4. Help identify affected floors in multi-story buildings during flooding.
Work on standards for interoperable 3D geo-visualization and exchange of city models is underway.This article highlights two new developments in this area, the Web 3D Service (W3DS) and CityGML, both of which have recently been brought to the "Discussion Paper" level within the OGC.I am one of two editors.

Integration of 3D Geodata within SDIs
An SDI can provide a network of registered, linkable and interoperable geo web services, which deliver geo-objects like buildings, bridges, digital terrain models (DTMs) and water bodies, and visual representations of them (such as 2D maps and 3D graphic models). Depending on specific needs, integration can take place at either the visualization level or data level.

Figure 1.Interoperability on the visualization level (top) and on the data response model level (bottom).(Click for larger image)
If the requirement is for integrated visualization only, it is sufficient to generate (partial) graphical representations for the spatial objects at their sources and to combine these, instead of combining the spatial data themselves.The most prominent example of this strategy is the OGC's Web Map Service.It allows retrieval of 2D maps (raster images) from different sources and systems.The maps can be combined using a Web browser by simply overlaying the raster images.

Unfortunately, 3D visualizations cannot be integrated on the image level, since rendered images are only 2D.If two systems render views of the same scene, these images may not simply be overlaid, because objects in the "lower" image can be covered up by objects in the "upper" image.The OGC's Web Terrain Service (WTS) is a portrayal service that generates perspective views of 2.5D or 3D scenes.As it delivers 2D images, it suffers from the described problem, limiting its capability with regard to possible integration of the outputs of different WTS on the client side.

Interoperability at the Visualization Level: W3DS

In order to overcome these challenges, the W3DS was brought to discussion within the OGC this year.The W3DS is a "real 3D" portrayal service in the sense that it generates 3D graphic elements from 3D geoinformation.So far, specification development has taken place with the Geodata Infrastructure North Rhine-Westphalia (GDI NRW) initiative in Germany.

In contrast to the WMS and the WTS, the W3DS aims at an earlier point of integration, on the level of graphical display elements, before the rendering step.To integrate different sets of display elements, it is necessary for each to have 3D geometries and use the same spatial reference system.These 3D scene graphs can be exchanged using standardized computer graphics data formats like VRML, GeoVRML, X3D, or Universal 3D (U3D).

Since most GIS, CAD and architecture/engineering/construction (AEC) software systems already export their data in one of these formats, W3DS functionality could be added by implementing a (small) W3DS adapter on top of the respective system.This way, 3D visualizations of different systems can be combined on the fly, even if their heterogeneous data models and storage concepts would prevent (quick) integration on the geodata level.In a disaster management scenario, visualizations from different systems (elevation data from a GIS, buildings from an AEC system and a gas cloud dispersion from a simulation system) could be combined.

Query parameters of the W3DS are very similar to those of the WTS, as can be seen from the following two examples.
You can click on one of the URLs below to render a scene, but you will need a VRML 2.0 viewer plugin installed.(One available here.) Below are examples of what you'd see if you rendered them.

Example 1:

Example 2:

Figure 2.Resulting 3D visualizations from the two queries shown above. The scenes are rendered and can be navigated in a Web browser using a VRML plugin.(Click either for larger image)

Figure 3 shows an example where a W3DS client adapter has been implemented for a Cosimir training simulator.A 3D building model is selected and fetched from a remote W3DS over the Internet and used simulate a fire fighting scenario.

Figure 3: Accessing a W3DS from a simulation environment.The 3D model was fetched over the Internet for training in a fire fighting scenario. Picture: W.Herzberg.Used with permission.(Click for larger image)

Interoperability on the Data Level: CityGML
In contrast to integrated visualization, actual data integration puts higher demands on the level of interoperability.First, the entities and data model to be integrated have to be known to the system that does the integration (semantic and schema interoperability).Second, a common exchange format is needed, that is supported by the geodata Web services of the SDI (syntactic interoperability).

The Web Feature Service (WFS), in conjunction with the Geography Markup Language GML3 as issued by the OGC and ISO, provide a framework for exchange of simple and complex 3D models.However, WFS and GML3 only establish syntactic interoperability, because GML3 is a meta-format. The effective structure of a GML3 document is determined by the definition of an application schema that is tailored to the specific application domain.

I will give a short overview of CityGML, an application schema for storage and exchange of virtual 3D city models.Like the W3DS, CityGML has been developed within the GDI NRW in Germany.Starting this month, the discussion will be broadened to the European Spatial Data Research (EuroSDR).Discussion of CityGML has also begun within the OGC, and we intend to submit a specification proposal to OGC by spring-time in 2006.

CityGML's aim is to reach a common definition of the basic entities, attributes and relations of virtual 3D city models that can be shared over different application fields.The targeted application areas explicitly include city planning, architectural design, tourism and leisure activities, environmental simulation, mobile telecommunication, disaster management, homeland security, vehicle and pedestrian navigation and training simulators.

CityGML does not only represents the graphical appearance of city models but especially addresses representation of the semantic representations for thematic properties, taxonomies and aggregations of digital terrain models, sites (including buildings, bridges, tunnels), vegetation, water bodies, transportation facilities and city infrastructure.The underlying model differentiates five consecutive levels of detail (LOD), where objects become more detailed with increasing LOD for both geometry and thematic differentiation.LoD0 defines a coarse regional model while the most detailed LoD4 comprises building interiors (see figure 4).CityGML files can - but don't have to - contain multiple representations for each object in different LOD simultaneously.

Figure 4.The five consecutive levels of detail LOD 0-4 of CityGML. Ascending LODs mean both an increase in geometric precision and thematic granularity.(Click for larger image)

Thematic objects that are especially relevant for disaster management include different types of digital elevation models, building features like rooms, doors, windows and balconies, and subsurface construction. Object classes have thematically rich attributes which allow for specific queries like 'What buildings have more than 10 storeys above ground?' or 'Where are buildings with flat roofs which are large enough to accommodate a helicopter?' CityGML is designed to accommodate terrain models with inconsistent resolutions - high resolution DTMs for regions with high flood risk can be embedded into large area DTMs at low resolution.

Since the geometry of 3D objects is normally represented by at least one closed solid, the computability of volumes and masses is facilitated.For example, in flooding or fire scenarios, it's possible to estimate how much water, smoke or gas will flow into a tunnel, pedestrian passage or building.The estimation of masses from volumes is also helpful for planning the removal of debris after an incident.

As I write this, system support for CityGML is currently available for a small number of 3D GIS and visualization tools.However, the potential and practical feasibility has been evaluated in a pilot project.Participation in the project included six groups from Germany (private companies, research institutions and the municipalities of Berlin, Hamburg, Cologne, DÃ1⁄4sseldorf and Leverkusen).We implemented a CityGML subset and demonstrated crosswise data exchange. A new 3D city model of Berlin was also redesigned in conformance with CityGML, and the 3D geodatabase, 3D editor and visualization system will communicate over transactional WFS using CityGML in the near future.

Further information including the XML schema definitions, test data, and an Open Source GML3 viewer application can be found on the CityGML homepage or from the following references.

Kolbe, T.H., Gröger, G., and L.PlÃ1⁄4mer, 2005, CityGML ï¿1⁄2" Interoperable Access to 3D City Models (PDF), in: Oosterom, Zlatanova, Fendel (Eds.): Proceedings of the Int.Symposium on Geo-information for Disaster Management on 21.-23.March 2005 in Delft, Springer

Lieberman, J., and J.Sonnet, 2003, Web Terrain Service (PDF), Open Geospatial Consortium, Discussion Paper, Doc.No.03-081r2

Quadt, U., and T.H.Kolbe, 2005, Web 3D Service (PDF), Open Geospatial Consortium, Discussion Paper, Doc.No.05-019

Published Sunday, December 18th, 2005

Written by Dr. Thomas H. Kolbe

If you liked this article subscribe to our bimonthly newsletter...stay informed on the latest geospatial technology

Sign up

© 2017 Directions Media. All Rights Reserved.