USE OF VIRTUAL 3D-LANDSCAPES FOR EMERGENCY DRIVER-TRAINING

Transcription

1 USE OF VIRTUAL 3D-LANDSCAPES FOR EMERGENCY DRIVER-TRAINING Dipl.-Ing. Bodo Randt * Head of Database Generation and Tools Dipl.-Inf. Frank Bildstein * Head of Ground Driving Database Team Dr. Thomas H. Kolbe + Professor and Chair of Geoinformation Science * Rheinmetall Defence Electronics, Bremen, Germany Simulation Division + Technische Universität Berlin Institute for Geodesy and Geoinformation Science Abstract 1 Police units, rescue and fire fighting services use flashing lights and sirens to indicate fast arrival needs at emergency situations. The drivers are stressed during these actions due to enhanced dangerous situations caused by the own aberrant behaviour and by the resulting unpredictable behaviour of the surrounding traffic. These emergency drives have an increased accident rate. The skills for vehicle mastery may be trained (partially) on real roads, the extra dangers by human interactions, either the own driver behaviour or the behaviour of other vehicles can be trained in simulators only to avoid high personal risks. All public authorities like police, bus & tram services tend to train in their own environments, means their native city. This poses a high workload on database generation as expensive geospecific solutions are preferred in opposite to multi-usable geotypical or generic solutions. The second part of the paper introduces a new standard to improve the source data situation for the generation of geospecific city areas, CityGML. 1 Presented at the 2007 IMAGE Conference Scottsdale, Arizona July 2007 Introduction Driving simulators are used for long time for training of car, truck, tram & train drivers. Besides the basic training just for learning low level skills for i.e. acquisition of driver licenses there are higher level simulators i.e. to avoid accidents for heavy trucks with hazardous loads, interaction with dangerous behaviours of people around trams or streetcars in addition to other traffic or emergency drives of police and rescue teams with very irregular traffic situations. In some simulator applications like i.e. ATC, air traffic control, foreign traffic was often done by other trainees which play the role of (multiple) other a/c to stress the ATC candidates sitting in the tower mockup. In driving simulation this is done w/o human help and typically the task of a vehicle simulation module (the military community calls this CGF computer generated forces). The foreign traffic acts like a traffic cloud around the own vehicle position to induce stress to the trainee. The foreign traffic rules are set by the overall law-driven situation with more or less degrees of freedom to bend the rules. Critical situations most often occur because other road users do not notice the

2 rapidly approaching emergency vehicle early enough and then they start panicking with unpredictable reactions. The crew of the emergency vehicle is challenged time and again especially when communication with the control centre is required. The development of geospecific databases especially for inner cities is an expensive process. There are numerous solutions available in the meantime which supply automated support for dense cities with a high degree of details. Mostly these solutions tend to be used for overviews like tourist aspects (city visualisation info), city planning aspects or low flying viewing applications with distance to ground. If it comes to ground driving distances, most of these visualisations show up with a lot of visual artefacts which throw the trainee out of the simulation and make him aware that he is sitting in a simulator. Typical source data provided by public authorities are vector data and of course elevation data. 3D is not on the source data list by most public suppliers. In Germany the Special Interest Group 3D (SIG3D), a mix of geo-related institutes of universities, public authorities and industry participation formed a data exchange model for inner city elements in 3D, so called CityGML. This approach is adopted by numerous land-registry offices in Germany and a proposed standard at the Open Geospatial Consortium (OGC). An introduction to the main components of CityGML is presented including their usage possibilities for efficient generation of driving simulator databases. - A realistic, extensive preparation of crews for emergency missions is difficult and expensive. - For safety, economical and ecological reasons, it is hardly possible to train emergency assignments in public road traffic. - Difficult situations may be illustrated by training videos and pictures, but these do not help to gain real experience. - Traffic accidents in connection with emergency assignments are bad for the image of the emergency services result in serious material damage and violation of people (on both sides ) are a considerable posttraumatic burden for the affected drivers and codrivers Fig. 1. Emergency drive at intersection The emergency situation problem - An emergency assignment involves more than just driving. - Driver safety training can only be the basis. Simulation based approach for emergency training In cooperation with driving instructors and several European police organisations for the qualified training of drivers a simulator providing a realistic presentation of emergency traffic events was developed which permits the driver to

3 train in the most important difficult situations without any risk. The degree of difficulty of the relevant training unit is defined by the instructor who can choose among numerous possibilities for the creation of exercise scenarios. Amount of road users and behaviour can be specified as well as the desired mistakes of individual road users. All road users are interacting with regard to the behaviour of the driver trainee. Urban as well as country roads and motorways are available at various seasons and weather conditions. Examples of rules of conduct: - formation of passage ways on a specific lane - formation of passage ways between two lanes - other vehicles are rushed by the emergency vehicle - no reaction of other road users, the emergency vehicle is ignored by other vehicles - deliberate disregard of special rights in the area of crossroads from a hidden position At the end of a simulated emergency assignment, specific critical situations can be replayed by the instructor and shown from various perspectives. This valuable help is very impressive and results in a faster and sustaining learning success. A further training goal can be achieved, by co-trainees monitoring the training mission in the simulator and participating actively during the debriefing. New driving exercises are simply prepared by menu-control at the instructor s control station. The traffic, which basically concurs with the rules, can be influenced by the instructor by setting specific events. The prepared exercises can be checked by means of the preview function. Existing exercises can be modified and stored. Additional executable exercises with different scenarios or degrees of difficulty can therefore be created without much effort. The simulated traffic adheres to the special rights of the emergency vehicle not earlier than the flashing lights and the siren are switched on by the driver in the simulator. During an assignment, the simulated road users do not only comply with the general traffic regulations, but also with a number of additional rules of conduct specifically implemented for such emergency assignments. Fig. 2. Bird s eye view of highway emergency situation problem Databases for emergency driver training The design of scenarios, exercises and emergency functionality of a driving simulator is one part of the process. An important aspect is of course the presence of a virtual environment enabling the training at the real location, means the geospecific aspect of the database. This lowers the degree of freedom for the modeller and poses at the same time a high workload in terms of the amount of objects to create. It is therefore of high interest to look for possible sources for geospecific 3Dobjects suitable for ground driving applications. One solution shows up in

4 new standard CityGML. It has been developed over the last five years by the Special Interest Group 3D of the Initiative Geodata Infrastructure North-Rhine Westphalia (GDI NRW). The data model behind CityGML is based on the ISO standard family 191xx. The implementation is realized as an application schema for the Geography Markup Language (GML3: ISO 19136) issued by the OGC and ISO. CityGML covers the geometrical, topological, semantic, and appearance aspects of 3D city models. The class taxonomy distinguishes between buildings and other man-made artifacts, vegetation objects, waterbodies, and transportation facilities like streets and railways. Spatial as well as semantic properties are structured in five consecutive levels of detail (LoD), where LoD0 defines a coarse regional model and the most detailed LoD4 comprises building interiors resp. indoor features. Included thematic objects, which are especially relevant for training simulators, are different types and combinations of digital elevation models and building features like rooms, doors, windows, balconies, and subsurface constructions. CityGML: Unified City Modelling CityGML is a profile of GML3 which implements an interoperable, multifunctional, multi-scale, and semantic 3D city model. This section presents the highlights of CityGML, starting with general concepts in the first section. However, the main focus is on the most important components of city models, i.e. the building model and the Digital Terrain Model. Initially, CityGML is specified using the graphical Unified Modeling Language (UML) according to the ISO standards 19101, 19107, and From UML diagrams, the XML schemas are derived by applying the transformation rules stated in ISO leading to a GML3 application schema represented in XML schema. Thus, it is ensured that CityGML can be processed by an increasing number of commercial and Open Source geoinformation systems (GIS) and geodatabase management systems. General Concepts of CityGML CityGML implements several novel concepts to support interoperability, consistency and functionality (see Gröger et al and the CityGML homepage). Levels-of-detail CityGML supports different Levels-of- Detail (LoD), which may arise from independent data collection processes and are used for efficient visualization and efficient data analysis. In one CityGML data set, the same object may be represented in different LoD simultaneously, enabling the analysis and visualization of the same object with regard to different degrees of resolution. Furthermore, two CityGML data sets containing the same object in different LoD may be combined and integrated. The level of detail does not only refer to the geometric resolution and accuracy but also to the semantic granularity. This means that with increasing LOD the decomposition of complex objects like buildings or roads into sub-objects becomes also semantically more differentiated. CityGML provides five different LoD, which are illustrated in Fig. 3. The coarsest level LoD0 is essentially a two and a half dimensional Digital Terrain Model, over which an aerial image or a map may be draped. LoD1 is the well-known blocks model, without any roof structures or textures. In contrast, a building in LoD2 has differentiated roof structures and textures. Vegetation objects may also be represented. LoD3 denotes architectural models with detailed wall and roof structures, balconies, bays and projections. High-resolution textures can be mapped onto these structures. In addition, detailed vegetation and transportation objects are components of a LoD3 model. LoD4 completes a LoD3 model by adding interior structures like rooms, interior doors, stairs, and

5 furniture. This is oriented up to support for Facility Management. LoD3 LoD0 LoD1 LoD2 LoD4 Fig. 3. The 5 Levels-of-Detail (LoD) defined by CityGML. The different LoD are also characterized by accuracies and minimal dimensions of objects. In LoD1, the positional and height accuracy of points may be 5m or less, while all objects with a footprint of at least 6m by 6m have to be considered. The positional accuracy of LoD2 is 2m, while the height accuracy is 1m. In this LoD, all objects with a footprint of at least 4m by 4m have to be considered. Both types of accuracies in LoD3 are 0.5m, and the minimal footprint is 2m by 2m. Finally, the positional and height accuracy of LoD4 must be 0.2m or less. By means of these figures, the classification in five LoD may be used to assess the quality of a 3D city model data set. Furthermore, the LoD category makes data sets comparable and thus supports the integration process of those sets. Coherent spatio-semantic modeling Another feature of CityGML is the coherent modeling of semantics and spatial (geometrical and topological) properties. On the semantic level, realworld entities are represented by application objects, for example buildings, including attributes, relations and aggregation hierarchies (part-wholerelations) between objects. On the spatial level, geometric-topological objects like composite solids and surfaces are assigned to semantic objects, which represent their spatial properties. Thus, the model consists of two hierarchies, the semantic and the geometric-topological, were the corresponding objects are linked by relations. The advantage of this approach is on the one hand, that every geometry knows to which semantic object it belongs (and hence, what its functionality is). On the other hand every semantic object (like a road, a tree, or a window) knows its location and extent in 3D space. In (Stadler & Kolbe 2007) we have shown that this knowledge is crucial for the development of procedures for the automated integration and homogenization of 3D datasets. Closure Surfaces and Subsurface Objects A novel concept in CityGML is the ClosureSurface, which is employed to seal objects, which are in fact open, but must be considered as closed to compute its volume. An airplane hangar is an example for such an object. ClosureSurfaces are special surfaces which are taken into consideration when needed to compute volumes and are neglected, when they are irrelevant or not appropriate, for example in visualizations. The concept of ClosureSurfaces also is employed to model the entrances of subsurface objects. Those objects like tunnels or pedestrian underpasses have to be modeled as closed solids in order to compute their volume, for example in flood simulations. The entrances to subsurface objects also have to be sealed to avoid holes in the digital terrain model (see Fig. 4). However, in close-range visualizations the entrance must be treated as open. Thus ClosureSurfaces are an adequate way to model those entrances.

6 aggregates CurveGeometries, Surface- Geometries and SolidGeometries. In contrast to BuildingParts, Building- Installations are smaller and only accessories, but not a constituent part of the building. Fig. 4. Passages are subsurface objects (left). The entrance is sealed by a virtual ClosureSurface, which is both part of the DTM and the subsurface object (right). The building model The building model constitutes one of the most important parts of CityGML. It allows the representation of thematic and spatial aspects of buildings, building parts and accessories in four levels-of-detail, LoD1 to LoD4. The pivotal class of the model is AbstractBuilding, which is specialized either to a Building or to a BuildingPart. In LoD1, the spatial extent of an AbstractBuilding is given by a SolidGeometry, which in this case is a simple block. A Building may be part of a BuildingComplex, which has at least one main building. In a LoD2 building (see Fig. 7 for an example), it is possible to distinguish the bounding surfaces as own thematic objects. These surfaces may be classified as Roof, Wall or Floor Surfaces. The geometry of these surfaces, however, is shared with the SolidGeometry that defines the whole building. An opening in a building is modeled by a ClosureSurface. The geometry of a LoD2 building is given by SolidGeometries, and additionally by SurfaceGeometries, which represent surfaces that are part of the building, but do not bound the solids of the building. The overhanging part of a roof is an example for such a surface. A LoD2 building also may have BuildingInstallations, for example chimneys, balconies or outer stairs. The geometry type of a BuildingInstallation is not restricted. It is specified by an Object- Geometry, which is the super class of the Fig. 5. Illustration of an LoD2 building, consisting of two building parts with two dormers represented as building installation features. In LoD3, buildings additionally may have Openings such as Windows and Doors. As discussed the beginning, the accuracy requirements of LoD3 are much higher than those of LoD2. LoD4 complements LoD3 by adding interior structures of buildings such as Rooms, which are bounded by Ceiling-, InnerWall- and InnerFloorSurfaces. Rooms may be aggregated to a GroupOfRooms, and may have BuildingFurnitures and interior BuildingInstallations. A BuildingFurniture is a movable part of a room, such as a chair or furniture, while a BuildingInstallation is permanently connected to the room. Examples are stairs or pillars. Doors are used in LoD4 to connect rooms topologically: the surface that represents the door geometrically is part of the boundaries of the solids of both rooms. As discussed earlier, the different accuracy requirements of LoD1 to LoD4 have to be applied to the building model as well.

7 Interfacing terrain and 3D objects A crucial issue in city modelling is the integration of buildings and the terrain. Problems arise if buildings float over or sink into the terrain, which is particularly the case if terrains and buildings in different LoD are considered. To overcome this problem, the TerrainIntersection curve of a building is introduced. This curve denotes the exact position where the terrain touches the building, and is represented by a closed ring surrounding the building (see Fig. 7 for an example). If the building has a courtyard, the TerrainIntersection curve consists of two closed rings. This information can be used to integrate the building and a terrain by pulling up the surrounding terrain to fit the TerrainIntersection curve. By this means, the curve also ensures the correct positioning of textures. Since the intersection with the terrain may differ depending on the LoD, a building may have different TerrainIntersection curves for each LoD. Fig. 6. TerrainIntersection curve (black) for a building. Fig. 7. TerrainIntersection curve for a tunnel object (white). The tunnel s hollow space is sealed by a triangulated ClosureSurface. The digital terrain model An essential part of a city model is the terrain. In CityGML, the terrain may be specified as a regular raster or grid, as a TIN (Triangulated Irregular Network), by break lines or skeleton lines, or by mass points. These four types are implemented by using standard GML3 elements. A TIN may either be represented as a collection of triangles, or implicitly by a set of 3D points, where the triangulation may be reconstructed by standard methods. A break line is a discontinuity of the terrain, while skeleton lines are either ridges or valleys. Both are represented by 3D curves. Mass points are simply a set of 3D points. In a CityGML data set, these four terrain types may be combined in different ways, yielding a high flexibility. First, each type may be represented in different levels-ofdetail, reflecting different accuracies or resolutions. Second, a part of the terrain can be described by the combination of multiple types, for example by a raster and break lines, or by a TIN and break lines and skeleton lines. In this case, the break and skeleton lines must share the geometry with the triangles. Third, neighbouring regions may be represented by different types of terrain models. To facilitate this combination, each terrain object can be provided with a spatial attribute denoting its extent of validity.

8 This extent is represented by a 2D footprint polygon, which may have holes. This concept enables, for example, the modeling of a terrain by a coarse grid, where some distinguished regions are represented by a detailed, high-accuracy TIN. The boundaries between both types are given by the extend attributes of the corresponding terrain objects. This approach is very similar to the concept of TerrainIntersection curves introduced in the building model chapter. Summary and Conclusion CityGML provides substantial information for low up to high quality city visualization including support for training simulation (Bildstein 2005) and urban disaster management tasks (Kolbe et al. 2005). Spatial objects and terrain models are represented by their geometry, topology, appearance, and semantic properties. The ability of maintaining different levels of detail makes it suitable for small to large area utilization. Since GML was designed by the OGC to serve as the standard exchange format for spatial data infrastructures, processing of CityGML is immediately supported by corresponding OGC web services like the Web Feature Service (WFS), Web Catalog Service (CS- W), and Web Coordinate Transformation Service (WCTS). The availability of data is steadily increasing as more and more municipalities decide to build up virtual 3D city models. In Germany for example the cities of Berlin (c.f. Döllner et al. 2006), Hamburg, Düsseldorf, Munich, Stuttgart, Frankfurt, Dresden, and Cologne are preparing to deliver their city data models in CityGML. LoD3 and LoD4 models currently are only available for selected areas or building complexes. This will change dramatically over the next years. The availability of LoD2 and LoD3 data models of cities will greatly improve the source data situation for the efficient development of geospecific driving simulation databases. References Bildstein, F., 2005: 3D City Models for Simulation and Training Requirements on Next Generation 3D City Models. In: Proc. of the Int. ISPRS Workshop on Next Generation 3D City Models, nd June, Bonn, Germany. Published in EuroSDR publication no. 49, online at CityGML 2006, Homepage of the CityGML standard, Döllner, J., Kolbe, T. H., Liecke, F., Sgouros, T., Teichmann, K., 2006: The Virtual 3D City Model of Berlin - Managing, Integrating, and Communicating Complex Urban Information. In: Proceedings of UDMS 2006 in Aalborg, DK Gröger, G., Kolbe, T. H., Czerwinski, A., 2006: CityGML Candidate OpenGIS Implementation Specification. OGC Doc. No Downloadable from Kolbe, T. H., Gröger, G., Plümer, L., 2005: CityGML Interoperable Access to 3D City Models. In: Proc. of the Int. Symp. on Geo-Information for Disaster Management on 21-23rd March, Delft, Netherlands, Springer Stadler, A., Kolbe, T. H., 2007: Spatio- Semantic Coherence in the Integration of 3d City Models. In: Proc. of the Int. Symposium of Spatial Data Quality ISSDQ 2007, th June, Enschede, The Netherlands.