| Home | |
| Consultancy | |
| Projects | |
| Development | |
| Training | |
| Support | |
| Products | |
| Portfolio/media | |
| Download | |
| Links | |
| Contact | |
| News | |
 |
|
 |
|
 |
Early in 2004, the Geographic Department of the City of Apeldoorn (a large city in the centre of The Netherlands) started investigating the options available for creating a realistic digital 3D model of the city. Both still images and real-time applications were required. This project is part of an ongoing movement within the city's organisation to continually increase the quality of the geographic data maintained in order to improve communication with the citizens.
by Hans van der Maarel
 |
Figure 1: the most basic version available, using block models for the buildings with an aerial photo draped over the entire scene. |
Introduction
Around the same time that the 3D investigations started, an urban redevelopment project was initiated. An old, mainly industrial, area on the edge of the historic city centre, which has since been surrounded by later residential development, is going to be turned into a residential and park area. This area is named Kanaalzone, after the canal that runs through it. The city decided to use this area as a pilot project for the 3D developments. This pilot project was started in cooperation with Red Geographics.
The people involved in development projects such as this one can get informed in detail about the project during special information sessions. The people can use these sessions to voice their concerns and ask questions. It is therefore important for both parties that the geographic information presented during such sessions is of the highest quality available.
People are understandably concerned about developments that impact their direct surroundings. A 3D application has the unique capability of offering a first-person perspective, which is often more effective than a map. This is especially true in situations where citizen interaction is required and specifically when it concerns people's living environments. Not every citizen has the ability to read a map the same way as a cartographer would. Over the years, 3D applications have proved very effective at providing the general public with a clear, easy to read, spatial form of communication.
Demands
The 3D development was subject to a number of demands that were being put forward by the city:
Technical
The data used for this project consists mostly of existing datasets of the city itself. These include the building contours and information on the roads, road signs, etc. and green areas (up to individual trees). In addition, a high-resolution aerial photo was used. Finally, it was decided that the 3D data, to be used for adding elevation to the buildings, was the AHN (Actueel Hoogtemodel Nederland). This is a very accurate, nationwide elevation dataset for The Netherlands.
After initial tests, it was realized that the AHN was not immediately suitable for generating the terrain itself. As the data is captured from laser altimetry, there is a lot of noise in the dataset. The point density (on average 1 point per 16 sq.meters) was too high for the terrain. It was decided to only use the AHN for the automatic generation of 3D buildings (either blocks or with sloped roofs) and use a different source for the terrain. The locations of the sewer manholes throughout the city are known in 3D, so they were chosen and used to interpolate the rest of the terrain. Since the pilot area is fairly flat, this could be done without introducing any major flaws.
The visualisation side of the project was done in Visual Nature Studio (aka VNS, developed by 3DNature), because it has strong GIS capabilities. This meant that some pre-processing of the source data (mainly available in Microstation format) was needed. For this, FME (Feature Manipulation Engine, developed by Safe Software) was used extensively. Several workbenches (data processing scripts) were set up to perform the various tasks needed. These included not only the transformation of the sewer manholes from a database format to an Arcview Shapefile, but also the conversion of the source Microstation files to Shapefiles and transforming it from the Dutch RD coordinate system to WGS84.
AHN (Actueel Hoogtemodel Nederland)
One of the most interesting bits of the preprocessing phase turned out to be the automatic generation of sloped roofs. In the initial tests, one elevation was assigned to every buiding contours. This was achieved through an FME workbench which did an overlay of the AHN points and the building contours. It then assigned the maximum elevation found within every building to the entire building. This resulted in 'blocks', which did not yield good results. In the case of the town's churches, where the tower is much higher than the main body, this proved especially unsatisfactory. With the addition of the roof break lines, digitized on top of a high resolution aerial photo, a much more accurate depiction of a building could be generated. Ironically, even though the AHN was too accurate for the terrain, it wasn't accurate enough to provide perfect results for the roofs. Important buildings are still modelled separately in a 3D modelling suite, textured with photos of the actual buildings and then imported into the final scene. Currently, 3 levels of detail can be offered in the buildings, depending on the requirements and availability of the data. The block models are still being offered because they can be created automatically. Over time, more and more buildings will be added as sloped roofs or as fully textured 3D models.
 |
Figure 2: showing generated buildings with sloped roofs, a fully modeled but untextured building and several fully textured buildings. Note the foliage and the road surfaces, all placed in VNS. |
Producing the Visualisation
After all the data was imported into VNS a couple of steps were taken to construct the final visualisation. Most notably, ecosystems were placed in areas indicated from the data of the local Parks Department. Ecosystems in VNS can contain images of actual foliage and can thus be made to look very realistic. Currently, only stock images of North American foliage species that shipped with VNS are being used, which will obviously need to be replaced in the future by the appropriate European species. Many aspects of foliage in VNS can be driven by GIS data, so the foliage heights and densities, among other ecosystem attributes, can be accurately portrayed.
The canal that runs through the project area has been 'sculpted' out of the terrain model using an Area Terrafector. Terrafectors are a concept in VNS where GIS-based vectors affect the terrain at a certain location. In this case, a terrafector was used to lower the terrain that was enclosed in the polygon that represented the canal. It was then filled with water to create a realistic effect. In a similar way, terrafectors were used to smooth the roads.
Two very distinct possibilities were considered for displaying the roads. The first option is to drape the high resolution aerial photo over the terrain. This provides an almost instantly recognizeable image. There are some disadvantages though. For example, shadows on the ground are obviously visible on the aerial photo as well. Any lighting set up in VNS would need to conform to this in order to keep it realistic. Furthermore, traffic shows up on the photo. Wherever there was a car on the street when the photo was taken, there is now a top-down image of that car on the ground. An added disadvantage of aerial photos is that they can of course only be used for an existing situation. The second option is to use data from the local Roads Department (mainly the road surface material) to assign textures to the various roads.
All of the placement of ecosystems, roads and water in VNS is driven by GIS-data, imported from shapefiles. The various VNS components are dynamically linked to these vectors. This allows for easy automation in case a different part of the city needs to be processed.
One additional task, that currently hasn't been fully researched, is determining the options available for 'dressing up' the image. Adding street furniture such as cars, trees, benches, signs, etc. (through importing the desired 3D models) or a realistic looking sky will make a scene come alive more and avoid the 'too clean' look. Though potentially time-consuming, this will certainly increase the realism factor and the user's perception of the scene as a whole.
A 3D application has the unique capability of offering a first-person perspective, which is often more effective than a map |
Real-time
For real-time purposes, the resulting 3D scene is then exported to one of the real-time formats supported by VNS, using the SceneExpress extension. Two options were considered:
Even though the performance of VRML, in terms of speed, is generally less than NatureView, it's still considered to be the main export format for providing the data to the public, VRML is an open standard and there are several viewers available in the form of browser plug-ins. A user can simply click on a link to a VRML document in his web browser, the plug-in will automatically be downloaded and installed and the VRML document will be opened. In the case of NatureView, the viewer has to be downloaded and installed first, then the NatureView file(s) need(s) to be downloaded and opened in the viewer. Another advantage of VRML is the option of adding interactive components to the scene. Regardless of the method used, the real-time solution would have to feature the option of 'walking' or 'flying' through the scene and positioning the camera at any desired point. Obviously, in order to appeal to a large audience, the interface would have to be kept as simple and straightforward as possible. In order to keep the speed of the real-time scene acceptable, it was necessary to reduce the level of detail contained in the scene. SceneExpress offers the necessary options to reduce the resolution of the terrain model and the textures used. This way, download times can be minimized, which is very important in the case of Internet deployment. The best results were found using VRML scene's with a new X3D browser. This offered a large increase in speed over the older VRML browsers, while still being available as a free plug-in for Internet Explorer.
 |
Figure 3: Close-up view. The car and lamp post are 3D objects. |
Towards the future
Even though the project is far from finished, it is possible to attach some conclusions to the first phase of it. The heavy use of GIS data and processes that either are or can be automated has paid off. Scaling the project up to cover the entire city, or redoing it for a different part is not going to be much more work. Obviously more buildings will need to be modelled separately, but apart from that it is just a matter of rerunning the automated process with new source data.
Scaling up the project is going to pose a difficult problem in terms of the amount of data. Especially in the case of real-time applications, either in combination with Internet deployment or not, this can be very serious. It is not unthinkable to have several real-time scenes available, where the level of detail decreases as the area covered increases. The lower-detail scenes would be used for general overviews of large areas, whereas the higher-detail scenes would be for specific purposes.
As time progresses, the processing power needed to provide the visual image that is desired, without compromise, will undoubtedly become available to a broader audience. Until that time, efforts will have to be made to find the best balance between speed and visuals.