Three-dimensional modeling with national coverage: case of The Netherlands

Abstract

Three-dimensional technologies have matured over the years. At the same time, 3D information is becoming increasingly important in many applications. Still it is not straightforward to apply the solutions that work on prototypes, small areas or for specific projects to 3D modeling of a whole nation. In the Netherlands, two initiatives are ongoing to address the issues of nation-wide 3D modeling. First, the initiative that aims at establishing and implementing a national 3D standard for large-scale topography with support of all stakeholders. Collecting and maintaining the large-scale data are the responsibility of local governments (mainly municipalities). The second initiative is led by the Kadaster (the organization responsible for topographic mapping in the Netherlands) and aims at automatically generating a 3D version of the 1:10 k object-oriented data-set based on a smart combination of the two-dimensional data with high-resolution laser data. Both initiatives are presented in this paper including results, open issues, and future plans.

Keywords:

• 3D modeling
• 3D standard
• country wide 3D mapping

1. Introduction

Three-dimensional information is becoming increasingly important in many applications. This is specifically true for densely populated countries where land and resources are scarce and the third dimension matters in spatial planning and other spatial applications. In addition, it has become feasible to look for 3D solutions, since the past years technologies for 3D geo-information have matured: Many local governments have 3D models and a large number of companies are providing services for constructing 3D models. Yet many governmental organizations face numerous challenges in introducing 3D models in their day-to-day processes.

To push 3D applications in the Netherlands, two initiatives have started to map the country in 3D. Both initiatives will be described in this paper.

The first initiative, described in Section 2, started in 2010 and focuses on the definition, establishment, and implementation of a national 3D standard for large-scale mapping (scale ~1:1 k). This national 3D standard is modeled as an application domain extension (ADE) of the international 3D standard “CityGML” established by the Open Geospatial Consortium (1).

The second initiative for national 3D mapping, described in Section 3, is the project 3D TOP10NL of the Dutch Kadaster, who also holds the national mapping agency. The aim of this project is to automatically reconstruct a 3D version of the object-oriented version of the 1:10 k data-set in a fully automatic manner and delivering these 3D data as open data to the community. The paper closes with conclusions and future work.

The 3D developments described in this paper may be considered as a solution limited to one specific country. However, the addressed implementation issues contain generalities, which are of interest for other countries and applications. In particular, because of experiments on wide 3D implementations beyond prototypes, small areas and project-based implementations are scarce.

2. Establishing and implementing a 3D national standard for large-scale topographic mapping

The national 3D standard for large-scale topography mapping in the Netherlands was established in 2011. It was established in the first phase of the 3D Pilot NL. 3D Pilot NL is a community of over 600 people interested in 3D developments coming from over 100 organizations (2). The Kadaster, the Ministry of Infrastructure and Environment, the Netherlands Commission for Geodesy, and Geonovum initiated the pilot in 2010. The aim of the pilot is to push 3D developments in the Netherlands by collaborating with all stakeholders on a test bed, test areas, and use cases. More information on the 3D Pilot can be found in Ref. (3, 4).

The new national 3D standard has been embedded in an information model, called “Information Model Geography,” i.e. IMGeo. This model is modeled as an ADE of the OGC standard CityGML (1).

CityGML models both geometry and semantics of thematic classes (buildings, vegetation, water, land, etc.) and distinguishes per object at different levels of detail. The height at ground level is represented in Level of Detail 0 (LOD0). Volume objects such as buildings and constructions can be modeled at different levels of detail in 3D. This can be a simple block model (LOD1), optionally with roof shapes (LOD2). It continues with windows, doors, and other exterior features (LOD3), to a fully developed interior model (LOD4).

IMGeo contains object definitions for large-scale representations of roads, water, land use/land cover, bridges, tunnels, etc. and prescribes two-dimensional (2D) point, curve or surface geometry for all objects. As the new version of IMGeo is modeled as CityGML ADE, it contains the same object definitions as CityGML and facilitates extensions to 2.5D representations (i.e. as height surfaces (digital terrain models); equivalent to CityGML LOD0) and 3D (i.e. volumetric; i.e. CityGML LOD1, LOD2, and LOD3) representations of the objects according to geometric and semantic principles of CityGML. For more details see Ref. (5–7) by van den Brink et al.

Section 2.1 presents more details on IMGeo and how it was modeled as CityGML ADE. Section 2.2 describes how the standard is currently being implemented in a nation-wide 3D coverage.

2.1. Information model geography

IMGeo describes how object-based, large-scale (between 1:500 and 1:2000) topographic features must be defined to make the national exchange of this information possible. Version 1.0 of IMGeo was published in 2007. Version 2.0 with support for 3D was completed in 2011. Minor changes resulted in Version 2.1 in November 2012. IMGeo 2.1 has a mandatory core and an optional part.

Data providers such as municipalities and organizations responsible for the road, water, and railway infrastructure are required by law to provide their objects that fall under the definitions of the IMGeo 2.1 core to a national “basic registry,” from which the objects are available via a national portal for reuse.

The mandatory core of IMGeo prescribes the 2D point, curve or surface geometry for all objects (roads, water, land use/land cover, bridges, tunnels, etc.), for which GML three geometry types are used. The most notable topological rule of IMGeo is that the complete set of polygon objects at surface level (height level 0) in the mandatory core must together form a complete coverage of the Netherlands without gaps or overlaps. The optional part of IMGeo allows 2.5D (surface) and 3D (volumetric) geometries for each object.

After it was decided that the national 3D standard should align to both the national 2D information model on large-scale topography (IMGeo 1.0) and the international standard CityGML, the integration of IMGeo and CityGML into IMGeo version 2.0 was the next step. This was realized by modeling all IMGeo classes as an extension of CityGML classes. In this process, the semantics of CityGML was followed as much as possible.

Not for all classes in the national model, an equivalent CityGML class could be found. If possible, this was solved by remodeling the classes in the national standard. Examples of remodeling national concepts are the CityGML class AuxiliaryTrafficArea applied for those parts of a road that are not used for traffic but formerly modeled as roads, and Vegetation, formerly modeled as CityFurniture for isolated trees and land use for plant cover areas. Often the remodeling resulted in improved modeling of the national concepts.

For one national concept a CityGML equivalent could not be found. This resulted in a class added to CityGML named other construction. It is meant for man-made constructions that are not building or building parts. See Figure 1 for examples.

Figure 1. Man-made constructions (shed, wind mill, and sedimentation bin) that cannot be modeled by core CityGML classes.

Since these constructions are most likely not limited to the Netherlands, adding a class Other Construction to the core model of CityGML may be considered and is submitted as change request to OGC (see change request 11-104 at http://www.opengeospatial.org/standards/cr).

Apart from extra classes, additional attributes and attribute values have been added in the national extension. To support the whole range of geometries, every class contains the additional attribute geometry2D and LOD0Geometry if not available in CityGML. The CityGML code lists were fully replaced by Dutch code values. The CityGML specifications do not define the attribute values and thus prevent a stable use. In the future, when the specifications will also contain those definitions, the Dutch national 3D standard could make use of these values. In addition, all classes share attributes for identification and versioning, for a reference to the data provider, for the object’s status (planned, existing, or historic), and for an indication whether a possible error in the data is under investigation.

Apart from the adjustments of the national information model, some improvements of the CityGML standard were identified, which were submitted to OGC as Change Requests, such as (a) including the LOD0 footprints of all feature types to support the full range of geometries (from 2D to 2.5D (surface) to 3D (volumetric)); (b) supporting non-horizontal building footprints in LOD0; and (c) enforcing a solid-geometry type instead of multi-surface for LOD1 and LOD2 buildings if it is known that the surfaces should form a closed surface. These requests (11-102, 13-025, and 13-028, respectively) are published at http://www.opengeospatial.org/standards/cr.

The IMGeo-CityGML application schema is available at Geonovum (8). Figure 2 shows the UML class diagram of tunnel. The yellow classes are CityGML; the other classes are the national extensions. The attributes geometry2D and LOD0Geometry are added to support the complete range of geometries starting from 2D.

Figure 2. UML class diagram of tunnel that shows the inheritance of the CityGML class for the Dutch class Tunneldeel (part of a tunnel).

2.2. Implementing the national 3D standard

Although the 3D standard is an important prerequisite for 3D applications, wide use of 3D is still not common practice in the Netherlands. The implementation of the 3D standard requires further insights and agreements. This also covers agreements on how to implement CityGML. CityGML allows freedom in its implementation, while a national standard requires clear implementation rules to assure uniform implementations.

For the implementation of the 3D standard, also more research was required to understand how the national 3D standard works in practice including the consequences of this new modeling method for IMGeo when used for both 2D and 3D data-sets: How to create and manage standard compliant data? How can this data be validated and maintained? How to upgrade 2D LOD to higher LODs? Also, more insight was needed on the ability to use 3D IMGeo data in CityGML-aware software, i.e. whether software systems are compatible with our extensions and which changes are necessary?

These questions have been studied in the second phase of the Pilot in which the 3D community developed ready-to-use tools to support wide and easy implementation of the 3D standard. The deliverables of 3D Pilot NL, Phase II (ran between September 2011 and December 2012) are available as an open source toolkit at Geonovum (9). Specific attention was paid how to align CityGML to the data standard in the building information model (BIM) domain Industry Foundation Standard (IFC). The 3D IMGeo toolkit consists of six parts, which are further detailed below.

1. Implementation specifications for the national CityGML extension that explains all technical details of the standard, for all classes and levels of details. As a national standard, IMGeo requires agreements on the precise implementation of the generic standard CityGML. These additional agreements both clarify and unify the demand for the national 3D data (not only buildings) and assure a countrywide uniform 3D data-set. These agreements can serve as input for tendering documents to assure that expectations of governmental organizations (who will mostly outsource their data acquisition) and companies (who will acquire the data accordingly) are harmonized. The resulting implementation specifications for CityGML-IMGeo (10, 11) were established after public consultation and also include a description of how each 3D data requirement can be checked.

2. Standard-compliant example data and an automated workflow. To understand how IMGeo works for the integrated 2D and 3D approach, example 3D IMGeo data have been built and made available to the public (see Figure 3). The objective of the example data is to help to understand the details of the national 3D standard and to serve as test data for software vendors. Besides the data itself, a workflow to automatically reconstruct the 3D data based on high-resolution laser data and 2D data has also been developed and made available, both as open source tool and FME (www.safe.com) workbench.

3. 3D validator (12), an internationally unique, open source tool that checks 3D geometries according to ISO19107 and GML. The validator implements the work of Ledoux (13). The validator software is available at Geonovum (12) and is implemented as standard functionality in FME by Safe software.

4. Guidelines for maintaining and updating 3D IMGeo data-sets based on tests with commercial software. To obtain the insights in maintenance and update of 3D IMGeo data, two challenges for private industry were issued. In the first challenge, six companies (i.e. Bentley, CPA systems, M.O.S.S., Safe Software, StrateGis, and Toposcopie) showed that they are able to edit and store the updated version of existing CityGML data of The Hague and use it in 3D applications, see Figure 4. In the second challenge, four vendors (Bentley, M.O.S.S., Safe Software, and CPA Systems) executed several tests on the 3D IMGeo example data that has recently become available. As outcome of this challenge, each of the four companies submitted a video in which predefined steps (14) were executed followed by a validation process at the end of the tests. These experiments proved that software that supports CityGML is also able to recognize and deal with IMGeo-data (as IMGeo is an extension of CityGML). This is important for the acceptance of 3D IMGeo in the Netherlands. The compiled video that summarizes these four company results is available at Geonovum (15).

5. 3D example applications: A website (www.3dpilot.nl) that collects and portrays 3D showcases to demonstrate the added value of 3D to policy-makers and inspire newcomers in the field. Although 3D applications are common practice for many professionals, 3D is new and considered as “complex” and “expensive” to others. To show the need and potentials for 3D and to offer a source of inspiration to the policy-makers and new comers in the field, the 3D Pilot built a website that collects and portrays examples of 3D applications that are already practiced. The growing interest for 3D shows from the about 1000 unique visitors worldwide in a few months.

6. Strategy and policy for aligning CityGML to data generated in BIM. Since the large-scale content of IMGeo touches data in the design and construction domain, specific attention was paid to aligning CityGML from the GIS domain to the data standard used in BIM, i.e. IFC.

Figure 3. 3D standard-compliant data, generated within the 3D Pilot NL.

Figure 4. Solar calculation on the CityGML model of The Hague, by Bentley in the CityGML-IMGeo contest.

In GIS as well as in BIM domains, it is acknowledged that the integration of both types of data is beneficial. BIM data are commonly modeled in the IFC standard and 3D GIS data can be encoded in CityGML. The two standards often model similar object types. Therefore, it is relevant to see how these two standards map, integrate, and interact with each other.

BIM (i.e. design) data can feed GIS data and GIS can serve as reference for BIM data. However, integration should acknowledge the differences between both types of data. To start with, the object description of BIM and GIS (e.g. CityGML LOD4) differs significantly. In addition, GIS is characterized by coverage of large areas (e.g. a complete city) and lower precision, while BIM is characterized by its local and very detailed approach, the limited number of construction models usually available in a city, and high precision necessary for reliable construction calculations. Also the modeling approaches of CityGML and IFC differ significantly, i.e. IFC models much more classes and allow also non-hierarchal relationships, where CityGML contains a limited number of classes structured via hierarchical relationships. Another core issue for bidirectional transformations is additional geometry types that are handled in the building industry and can be captured in IFC instances (16). Among them are Boundary Edge Representations and Constructive Solid Geometry (CSG), which are frequently used as implicit capturing formats while CityGML is limited to explicit polygonal representations. Although polygonal representations can be derived from these geometry types in a straightforward manner (thus transforming IFC to CityGML), it is impossible to generate e.g. efficient CSGs from triangulated surface representations.

Several studies (17–20) have shown that a conversion between IFC and CityGML is possible. However, because of the different modeling approach of both information models, there is not one optimal nor uniform conversion.

Therefore, based on the experiments and a study on best practices within several governmental organizations, the 3D Pilot worked on making agreements how to best realize the alignment between the two standards. Currently, an object catalog is being built that provides a common language for the two domains. These agreements are important to define a unique mapping between IFC and IMGeo-CityGML to make sure that a conversion always happens in the same meaningful way. This will also avoid the currently common situation that the rich semantics of IFC is lost because all objects are converted in the GenericObjectClass. Also, it may help to model according to specific rules in IFC to make sure that specific CityGML concepts can be derived (e.g. LOD2 Buildings) from the IFC data. Those agreements will be formulated as recommendations to the relevant standardization organizations, i.e. as change requests to BuildingSmart (21) and OGC for generic issues and to national standardization organizations for the national specific issues.

Because IFC and CityGML both serve different applications, it is important that both the original IFC source data and a CityGML representation are available and that CityGML objects explicitly refer to their interrelated IFC objects and vice versa.

The integration between the source IFC data and the 3D CityGML data can be maintained through a link between the two representations. In CityGML, one can refer to an external object via “external references.” This reference maintains the link to the external objects from which the CityGML data were derived. One CityGML object can contain more of such external references. The externalReference is a URI (either URL or URN). Every object in an IFC model that is a subclass of IfcRoot (all semantic classes) has an UUID identity that is compressed into a unique ID within the specific data-set, for example 3QbcAsYsg7Hvx$4VHzijdF. This ID can be converted into a 128-bit UUID via a publicly available method and can be used in the CityGML external reference.

For example, linking a CityGML Building to a IfcBuilding can be done via an URN based on the decompressed GUID of the IfcBuilding (urn:uuid: [UUID]) or based on the compressed ID (urn: ifc-guid:3QbcAsYsg7Hvx$4VHzij).

Both the IFC GUIDs and the uncompressed UUID can be used in the reference link. The compressed ID can be converted into an uncompressed ID and vice versa. Another option is to use an externalReference that contains an http URL. The advantage is that it is both an identification and a reference to the location where more information can be found about the object. In contrast, a URN is only an identification; to find more information about the object, an extra step is required to resolve the URN to a location on the internet. An example is the BIM Server (www.bimserver.org) where every IFC object has a URL. This could simply be used as CityGML externalReference for every object that was derived from an Ifc object.

This next example shows a CityGML XML fragment with in bold an externalReference:

Table

<core:cityObjectMember>

<bldg:Building gml:id=“Build0815”>

<core:externalReference>

<core:externalObject>

<core:uri>urn:uuid:550e8400-e29b-41d4-a716-446655440000</core:uri>

</core:externalObject>

</core:externalReference>

<bldg:function codeSpace=“http://www.sig3d.org/codelists/standard/building/2.0/AbstractBuilding_function.xml”>1000</bldg:function>

<bldg:yearOfConstruction>1985</bldg:yearOfConstruction>

<bldg:roofType codeSpace=“http://www.sig3d.org/codelists/standard//building/2.0/AbstractBuilding_roofType.xml”>1030</bldg:roofType>

<bldg:measuredHeight uom=“#m”>8.0</bldg:measuredHeight>

<bldg:storeysAboveGround>2</bldg:storeysAboveGround>

<bldg:storeyHeightsAboveGround uom=“#m”>2.5 2.5</bldg:storeyHeightsAboveGround>

<bldg:lod2Solid> ... </bldg:lod2Solid>

</bldg:Building>

</core:cityObjectMember>

A similar approach of referring to external objects is available in IFC and therefore this solution can establish an integration on the semantic level. It should be noted that this reference mechanism does not solve the problem of mapping the boundary-presentations of CityGML to the component-assemblage representations of IFC. Instead, the external references make it possible to use IFC as a kind of additional LOD5 representation of CityGML objects. This is a simpler approach, than modeling IFC as ADE (18). However, it prevents geometry to be reused in the GIS database, which is accomplished in the IFC ADE where GIS and IFC data are integrated at a more fundamental level.

3. 3D TOP10NL

The previous section presented the initiative of nationwide large-scale 3D mapping in a collaboration of many stakeholders. This section presents the initiative of nationwide 3D mapping of one organization, i.e. the Kadaster, the organization responsible for topographic mapping in the Netherlands.

To meet the increasing demand for 3D information, the Kadaster is investigating how to extend the 1:10 k data-set (TOP10NL) into 3D in collaboration with the universities of Twente and Delft. The aim is to have a 3D version of the object-oriented 2D data-set covering the whole country. Consequently, the map objects should still be available in the 3D model but now with the 2.5D (i.e. height-surface) and 3D (i.e. volumetric) representations.

Although IMGeo has been fully prepared for extension into 3D by integration of the information model with the OGC CityGML standard, 3D TOP10NL will serve other objectives. TOP10NL data are available nationwide while 2D IMGeo data will only be generated in the coming years. In addition, TOP10NL is less detailed than IMGeo and therefore better suitable for fully automatic 3D object reconstruction since fewer details are present (therefore, less special cases). We assume that the resulting data-set is sufficient for a nationwide data-set (i.e. acceptable performance for nationwide applications), and that it can be further refined (for example, with 3D IMGeo data) when applied in future projects.

Some tests on generating 3D TOP10NL fully automatically have been done in the past years (22). Currently, the research results are made further ready for practice. The developments of 3D TOP10NL builds on the insights obtained by the pilots on 3D IMGeo, since the techniques to obtain LOD0 and LOD1 representations from a combination of 2D data and high-resolution height points are similar.

3D TOP10NL will be generated from the 1:10 k data-set (see Section 3.1) and high resolution laser data (see Section 3.2). The specifications of 3D TOP10NL and the generation of the data according to these specifications are described in Section 3.3.

3.1. Source data: The 2D topographic dataset

The main classes in TOP10NL are: Road, Terrain, Water, Railway, Layout Element, Registration Area, Building, Geographical Area, and Functional Area.

The terrain, road, and water objects that can be seen from above form a complete partition of the country, without any gaps or overlap. Consequently, buildings, and also functional and geographical areas, overlap with other objects. In addition, infrastructure objects can cross (i.e. overlap in 2D). This is modeled using two attributes assigned to infrastructural classes with polygon geometry (water and road): a “type of infrastructure” attribute, which models whether the infrastructure object is a connection or a crossing and the “height level” attribute. This last attribute models the relative order of objects where a value of “0” indicates that the object is on top of a stack of two or more objects (i.e. visible from above). All objects at height level “0” constitute the planar partition.

3.2. 3D source data: high resolution laser data

3D TOP10NL is generated by combining the TOP10NL vector data with the national height model of the Netherlands (called AHN2), which is acquired by airborne Lidar systems. The first version of AHN (with a density of at least one point per 16 square meters, with the exception of forests where it is at least one point per 36 square meters) was completed in 2003. In the period of 2009–2012, the second version of the data-set was acquired with an average point density of 10 points per square meter. Currently a third version, possibly enriched with pulse count information, is being considered.

A useful property of AHN is the filtering step that separates points on ground and points on elevated objects such as trees and buildings (see Figure 5).

Figure 5. AHN2 points on elevated objects (filtered). The colors represent height values.

3.3. Specifications and generation of the 3D TOP10NL dataset

Not all TOP10NL classes are relevant or suitable for an extension to 3D, for instance functional areas (e.g. zoo, cemetery) and point-based features (e.g. striking objects) are not. We therefore selected the most appropriate classes, which are road, water, terrain, and buildings.

The type of 3D representation that is generated (i.e. 2.5D or 3D) depends on the class. Following the characteristics of the TOP10NL objects, we decided to obtain volumetric geometries (3D) for buildings and height surface geometries (2.5D) for the other objects (road, water, and terrain). Multi-level infrastructural crossings are represented through surface geometries that connect in space (Figure 6).

Figure 6. 3D TOP10NL of an urban scene, including a bridge.

“Forest” (which is a type of terrain) is a specific case, since the AHN2 data contains two products at those locations: the point data at the terrain level and point data representing the heights of the trees. To represent both types of information in the resulting data-set, we create a height surface from the tree heights and extrude it downwards to the terrain level to obtain volumetric objects. Both types of height (tree heights and terrain heights) are relevant information at those locations.

For the automated reconstruction, we use the algorithms and tools developed by the University of Twente (23). The generated LOD0 representation of the 2D data is more than a drape of the 2D data over the digital terrain model. It consists of a triangulated surface per polygonal object, generated by means of a constrained triangulation with the polygonal boundaries as constraints. All these triangulated surfaces together form a topological surface of the terrain (as in 2D) with height variances modeled within a polygon. If necessary, extra points are added on the boundaries to better reflect the height variance.

The reconstruction of a topologically correct LOD0 surface requires further attention. The triangulated surfaces are reconstructed for each polygon separately based on the height points that fall within that polygon. Consequently, gaps may occur at polygon boundaries that are neighbors in 2D may not necessarily in 3D. The approach of Oude Elberink (23) was followed to fill these gaps. In this approach, heights on polygon boundaries are adjusted depending on the types of neighbors. The result is a closed 2.5D surface.

Several challenges need further attention before 3D TOP10NL can be put in production. These are:

1. How to reconstruct the data for the whole of the Netherlands? How to upscale to larger areas? Can this be done by generation per partition and gluing afterwards?

2. How to maintain and update the 3D data: in a database environment or by regenerating complete areas in case of updates? How to assure that 3D TOP10NL is consistent with 2D TOP10NL?

3. How to deliver the data? As files (GML or Shape?) and/or in a Webviewer (WebGL or KML?)? Is it possible to make a data-set of the whole country available at once or should we deliver the data-sets of specific areas on demand?

4. Conclusions and ongoing work

This paper presents two initiatives in the Netherlands aiming at applying 3D solutions that work on prototypes, small areas, and specific projects to 3D mapping of a whole country.

The main conclusion of these two 3D initiatives that are studied within a national 3D community is the change of vision concerning 3D in the Netherlands. At the start, many saw that 3D had potentials, but did not know how to deal with 3D, while now ambitions for 3D have become matured and focused.

Several aspects appeared to be crucial for wide adoption of 3D. First, the engagement of many stakeholders was important to gain the necessary support. The collaboration of these stakeholders facilitated sharing knowledge on the wide variety of topics in the 3D domain, which was crucial to make significant progresses in 3D. Second, the alignment to an international standard as well as to ongoing 2D efforts makes that 3D applications become in reach for governmental organizations. Finally, it was found important that a number of national organizations took the responsibility for 3D mapping at national level. Although the 3D community is important for the 3D progresses reported in this paper, a national organization is needed to take up the necessary actions to establish a national 3D standard, to facilitate the 3D community, and to anchor the results.

The work of 3D implementation at national level is not finished and several issues remain. These are currently taken up by the national 3D Special Interest Group that has been specially established for this purpose. The objectives of this 3D SIG are to address the still open 3D issues in collaboration with all stakeholders. Among these issues are open issues concerning implementation of the 3D standard and the implementation of 3D TOP10NL, the integration of 3D city and landscape models with the subsoil (i.e. geology and cables & pipelines) (17, 24, 25), further alignment between BIM and GIS, and 3D extensions in other domains such as spatial planning and noise modeling (26).

Notes on contributors

Jantien Stoter is an associate professor at the Section GIS Technology, Delft University of Technology and leading the Theme Group Spatial Information Infrastructure. She is also researcher at the Kadaster and works at Geonovum as Geo-ICT consultant. Her research interests are 3D modeling, 5D modeling, and automated generalization.

Linda van den Brink is an information analyst at Geonovum. She develops standards for geo-information and leads harmonization initiatives to better align those standards. She is expertized in GML, XML, and related standards as XML Schema and XSLT.

Jakob Beetz is an assistant professor at the Design Systems Group at the Department of the Built Environment of the Eindhoven University of Technology. His research interests are BIM, Interoperability, and the Semantic Web.

Hugo Ledoux is an assistant professor in GIS at the Delft University of Technology in the Netherlands. His research focuses on topological data structures, the development of algorithms for three dimensional modeling, and the use of Voronoi diagram for environmental modeling.

Marcel Reuvers is a standardization coordinator at Geonovum. His core activities include international standardization like OGC and ISO/TC 211, Inspire, data harmonization, egovernment and BIM.

Paul Janssen is a standardization officer at Geonovum. His core activities include semantic modeling, cross-domain harmonization, and validation and testing against data specifications.

Friso Penninga is a senior Geo-ICT consultant at the City of The Hague and consultant Geo-ICT at Geonovum. His research interest is 3D modeling.

George Vosselman is a professor of Geo-Information Extraction with Sensor Systems at the University of Twente. His research interest is in large-scale mapping using airborne and terrestrial imagery and point clouds.

Sander Oude Elberink is an assistant professor at the University of Twente. His main research responsibilities are (semi-) automated acquisition of 3D geo-information.

Acknowledgements

We would like to acknowledge the contributions of all 3D Pilot participants who have been very important for the achievements in our country. This research is supported by the Dutch Technology Foundation STW, which is part of the Netherlands Organization for Scientific Research (NWO), and which is partly funded by the Ministry of Economic Affairs (project code: 11300).