CityGML implementation specifications for a

CityGML implementation specifications for a countrywide 3D data set: the case of the Netherlands

ABSTRACT This paper discusses and presents the specifications of a countrywide 3D data set for the Netherlands and the best practices to generate 3D data accordingly. The specifications extend the OGC 3D standard CityGML so that it is aligned to national requirements. Although CityGML offers a solid base for 3D information modeling, we have met the problems of CityGML being a generic standard resulting in too much flexibility and in some cases ambiguity when implementing it at a national level. This is why we experimented with the production of test data and use cases to find the best way of CityGML implementation for obtaining high-quality and consistent data for the whole of the Netherlands. The obtained insights led to the refinement and the extension of the CityGML specifications. This paper presents the resulting implementation specifications. In addition, to show how compliant 3D data can be created with these specifications, we present a workflow to generate 3D information (compliant with these specifications), starting from existing 2D/3D raw data. Also, a 3D validation tool has been developed to be able to evaluate 3D information against the defined specifications. Currently these specifications have been offered to OGC as best practises. A proposal for an OGC Interoperability Experiment to define and validate data quality requirements of CityGML data in order to obtain clear implementation guidelines is currently under review at the OGC.

1. INTRODUCTION While techniques for the production of 3D geo-information have matured, it is still not straightforward to construct, from the acquired 3D data, geo-information that can be used in spatial applications. For use in applications where spatial analysis is required (and not only

for visualization), 3D geo-information should be for instance geometrically and topologically valid, and semantic attributes should be attached to the different objects, see Figure 1.

Figure 1: geometrically and topologically valid 3D data

With the wide adoption of the 3D standard “CityGML” - established by the Open Geospatial Consortium (OGC) in 2008 - as an international standard, the amount of 3D datasets has increased rapidly, in tandem with the range of applications to which 3D is being applied (e.g. solar mapping, noise modeling, cadaster, etc.). The standard CityGML (OGC, 2012) is an application-independent information model and exchange format for 3D city and landscape models. The standard is meant as a generic standard for modeling topographic features, e.g. roads, buildings, land use. More restrictions to specify 3D information for specific applications can be modeled by the definition of an extra formal schema based on the CityGML schema definitions. Such a schema is called a CityGML Application Domain Extension (ADE). Further details about CityGML can be found in Gröger and Plümer (2012).

The quality of the 3D data being used in spatial analyses is of the utmost importance to the value of the outputs. However, the evaluation of the quality of CityGML data has not received the attention it deserves in practice. This is partly because GML - the basis to model geometric primitives - is a generic standard and allows an implementation freedom, and also because CityGML does not offer sufficient guidance on how to uniformly and unambiguously

implement the standard: while conformance requirements do exist, they do not cover checking the integrity of CityGML geometries. Furthermore, implementation specifications do not currently exist for 3D primitives, with the exception of the modeling handbook published by the German 3D Special Interest Group - data quality working group. See SIG3D (2013a and 2013b). In short, CityGML requires further attention to be able to produce consistent and high-quality 3D geo-information encoded in CityGML.

This application paper presents the implementation specifications for CityGML that we developed based on obtained insights from experimenting with CityGML data and use cases within the “3D Pilot NL”, a test pilot ran in the Netherlands in the last few years.

3D Pilot NL The 3D Pilot NL was initiated in 2010 by four organizations (Kadaster, Geonovum, the Netherlands Geodetic Commission and the Ministry of Infrastructure and Environment) to promote and foster the use of 3D geo-information in the Netherlands. In this pilot, over 65 organizations collaborated on the production of 3D geo-information for a test area, and on the execution and documentation of use cases. The 3D Pilot, and the 3D Pilot results, are presented in several other publications (Stoter et al., 2011) (Stoter et al., 2013). This paper focuses on the technical specifications to produce 3D geo-information compliant to the national 3D standard and a methodology to automatically generate 3D geo-information accordingly. The activities in the 3D Pilot showed an urge for a national 3D standard. After an extensive analysis on available 3D standards and formats (Stoter et al., 2011), CityGML appeared to be the best candidate for the national 3D standard. In a next step, the Dutch national 3D standard, called IMGeo (Information Model for Geography), was defined as ADE of CityGML. IMGeo integrates 2D and 3D information modeling. It contains definitions for large-scale representations of objects such as roads, water, land use/land cover, bridges and tunnels. The accuracy requirement for water, vegetation and land use is 60 cm; for the other

object types this is 30 cm. As CityGML ADE, the classes in the information model IMGeo inherit from the equivalent CityGML classes. This facilitates extensions of the 2D objects to 2.5D (i.e. height surfaces; equivalent to CityGML LOD0) and 3D (i.e. volumetric representations as in CityGML LOD1, LOD2 and LOD3) according to geometric and semantic principles of CityGML. See Van en Brink at al (2013a; 2013b) for details.

Previous work Many others have done significant work in the area of CityGML implementation. For example, North-Rhine Westphalia in Germany was the first state to provide a state-wide 3D model consisting of 3D roads, railways, an elevation model, and 3D buildings employed for noise dispersion mapping (Czerwinski et al., 2007) (Czerwinski et al., 2006). In addition, (Portele, 2009) wrote a CityGML implementation profile for Urban Topographic Data Store. Another important achievement in CityGML implementation is the extension of the German national cadaster model ALKIS by 3D building models. In this project a CityGML profile has been defined and most states in Germany provide 3D building models according to this profile. In addition INSPIRE data specifications for buildings contain a 3D building profile in line with the CityGML specifications for buildings (INSPIRE, 2013). Finally, different ADEs have been developed, examples are noise (as used in the German state North-Rhine Westphalia and as documented within the CityGML specification), utility networks (Becker et al., 2013) Real Estate Management, Robotics, BIM and hydrography (see (CityGML ADE, 2013)).

This paper The objectives of the specifications as topic of this paper are twofold. Firstly, the commonly agreed specifications ensure that the generic CityGML standard is interpreted in a uniform way in the acquisition process. Secondly, the specifications define more precise specifications in situations where CityGML allows freedom. Therefore, the specifications contain additional agreements (requirements) to apply the generic CityGML standard in a consistent manner.

That it is not straightforward to implement CityGML in a consistent manner, as explained in Benner et al. (2013). The technical specifications allow governmental organizations to either outsource the production of 3D geo-information in a uniform way or to straightforwardly produce the 3D geo-information themselves. It also encourages the industry to invest in production processes that respects the international standards. The paper may seem to address a solution limited to one specific country. However the presented implementation solutions are, in our opinion, useful for others who are looking for solutions to produce 3D geo-information in a consistent manner. It is therefore important to understand that IMGeo does not (only) refer to a national standard: IMGeo is modeled as a CityGML profile refining the standard. Consequently “IMGeo” data is CityGML data and the experiences obtained with 3D IMGeo data as described in this paper are applicable to CityGML data. Since IMGeo refers to a specific implementation of the standard, we prefer to use “IMGeo” in this paper. In addition, among the stakeholders involved in this project are many internationally leading vendors from abroad. Therefore, the experiences of the 3D pilot have contributed to developments and growing insights worldwide. This is why the delivered instruments and documents have been offered as best practice and discussion material to the OGC working group on CityGML. See for example the discussion paper submitted to OGC (Van den Brink et al, 2012).

The main topic of this paper is the definition of implementation specifications for CityGML. Section 2 describes the points of departure of the specifications, while section 3 details the requirements defined in the implementation specifications. To show how compliant 3D data can be created with these specifications, we developed a workflow taking as input 2D data in combination with already acquired 3D raw data sets. Section 4 presents the developed automated workflow that reconstructs 3D IMGeo compliant information from 2D IMGeo and point cloud data according to these requirements and

explains the validation that we apply to test the output of the workflow. The 3D source material (i.e. raw data) to be used for 3D geo-information reconstruction plays an important role in the requirements, also addressed in the implementation specifications and summarised in section 5. Conclusions and further work are presented in Section 6.

2. STARTING POINTS OF THE IMPLEMENTATION SPECIFICATIONS

The implementation specifications are driven by several points of departure that have been identified by the 3D Pilot experiments. These are the following. (Semi) automated reconstruction based on existing source material The starting point of the specifications is that they should define content and meaning of 3D data in such a way that the generation of 3D information could be performed as automated as possible based on data already available at governmental organizations: large-scale 2D topographic data (IMGeo), building data (maintained in the building and address register) and high-resolution airborne lidar sample points. In the Netherlands, a countrywide Lidar dataset is available as open data since March 2014. This data set is called AHN2: the national height model of the Netherlands (Actual Height model of the Netherlands). It has an average point density of 8 points per square meter, and its total number of points is about 640 billions. A useful property of the AHN points is the filtering label that distinguishes points on ground from points on elevated objects such as trees and buildings. Lessons learnt as input for the specifications Several experiences served as input for the specifications: experiments within the 3D Pilot to automatically generate 3D information from geometries of buildings, 2D IMGeo, and AHN2; experiences of cities Rotterdam and The Hague who outsourced the production of 3D CityGML data for their areas in 2009 respectively 2010; and the experiences of Universities of Twente and Delft to automatically reconstruct and validate 3D information. Also the quality guidelines for CityGML data of SIG3D specifically focusing on geometries of LOD1-

LOD3 buildings were used and refined (SIG3D, 2013a, 2013b). Finally, companies with long experiences in reconstructing 3D information have provided valuable comments for the final specifications. Levels of detail The technical specifications define different requirements for each class and each level of detail (LOD). CityGML distinguishes both at the geometric and semantic level between thematic concepts (buildings, vegetation, water, land use, etc.). LOD0 represents the terrain. Building roof edges and footprints can also be represented in CityGML LOD0. A building (or other volumetric) object can vary from a simple block model (LOD1), with roof shapes (LOD2), with windows, doors and other exterior features (LOD3) to a fully detailed interior model (LOD4) with or without texture information (called ‘appearance’). The implementation specifications contain most requirements for LOD0, LOD1 and LOD2, driven by the principle of automated reconstruction, which is feasible for levels of detail up to LOD2. Use case dependent requirements Defining requirements for the reconstruction of 3D information according to 3D IMGeoCityGML (with or without texture) starts with making choices with respect to the 2D and 3D source material to be used, the required accuracy and precision, etc. The choices that have to be made are for example: Choices for LOD0: 

How to represent vertical surfaces in the Digital Terrain Model with a TIN? Most GIS systems do not accept vertical faces.



Should all objects above the ground have LOD0 representations, also the ones above surface level (e.g. multilevel crossings)?



How to represent curved surfaces since CityGML only allows linear geometries?



Should building footprints (LOD0) be horizontal (as in the CityGML specifications)?

Choices for LOD1 buildings:



How to determine the height of a LOD1 building? As maximum/average of the laser point data that fall within the polygon, or as the median because it filters out the mismatched points at the boundaries?

Choices for LOD2 buildings: 

Should the LOD2 representation of buildings use the 2D geometry as base? The laser point data do not always match with the 2D footprints, resulting in ‘strange’ geometries.



How to represent roof surfaces in LOD2, with roof overhangs or not?



Is it better to represent a LOD2 building with a GML:Solid or with a GML:MultiSurface?

Choices for other object types than buildings: 

How to represent a tunnel or bridge at several levels of detail in CityGML? This is only briefly described in the standard.

•

How to represent LOD1, LOD2 and LOD3 for vegetation, trees etc?Choices with respect to quality:Which requirements of aerial photographs are necessary to automatically obtain height points from image matching?



Which quality criteria are needed for the generated 3D data?

Obviously, these choices depend on the intended use of the information. Therefore the specifications address several use cases and a table that divides the requirements into four categories of 27 use cases. Examples are determining the maximum allowed building height in spatial plans, noise modeling, solar calculation and hydrological modeling. Depending on the intended use, an organization can derive the relevant 3D IMGeo requirements.

3. THE REQUIREMENTS IN THE SPECIFICATIONS

This section details the implementation specifications that were developed in our project for the various IMGeo classes at the different levels of detail. The ordering of levels of details in CityGML seem to imply modeling more details when going from LOD0 to LOD4. This is true when going from LOD1, to LOD2 and LOD3.

However at LOD0 (and 2D level), there may be very high level of precision and detail as shown by our modeling examples. Therefore LOD0 representations on the one hand and LOD1-LOD3 representations on the other hand may be determined by object types that one needs to model by the intended applications. Some applications (hydrological modeling for larger areas, flooding analyses, etc.) may never be interested in volumetric geometry types (i.e. LOD1 to LOD3), but the more in detailed LOD0 representations. Also various detail levels can be applied to the interior modeling at LOD4. Because of this, IMGeo land use, road and water objects are only represented in LOD0. Other object types (buildings, bridges, tunnels, vegetation, and city furniture) also contain a definition at the higher level of details.

Table 2 presents a selection of the 40 requirements defined by the technical specifications. The requirements are divided into requirements for: -

generic issues, such as being compliant to the latest version of IMGeo and CityGML, and the coordinate reference system to be used.

-

LOD0 (2.5D) representations of 2D land use, water and road objects

-

LOD0-LOD1-LOD2 Buildings

-

LOD1-LOD3 Bridges and Tunnels

-

LOD1-LOD2 Vegetation-plant cover and LOD2-LOD3 Vegetation-trees

-

LOD2-LOD3 CityFurniture

-

texture

Because of the limited space available, this section will only detail the specifications for land use, water and road objects (Section 3.1) and for buildings (section 3.2). For the complete set of requirements covering all classes, see the document itself (available in English) (Geonovum, 2013a).

Table 1: A selection of requirements to unambiguously define the 3D information to be reconstructed Requirement 4 Every object in IMGeo is represented by a LOD0 geometry i.e. a TIN surface (triangulatedSurface) per object (tessellation of the object’s footprint) . The LOD0 terrain is formed by a collection of such adjacent TIN surfaces, with recognizable object boundaries (constrained TIN).

Requirement 5 The LOD0 geometries of all IMGeo polygons (water, road, building, land use, vegetation) at ground level should form a planar partition in 2.5D (no holes or overlap).

Requirement 7 Vertical surfaces in the TIN may not occur, because many GIS software crashes on such data. Instead, vertical surfaces should be approached by maximum sloping surfaces. How this should be done depends on which objects are left and right of the vertical jump. (More details are given on the specifications.)

Requirement 8 When very precise vertical intervals between specific objects are necessary, this should be recorded in the technical specifications. A minimum height should be defined and vertical intervals must be visible. Examples are the height jumps at the location of curbs.

Requirement 13 The ground surface of a building at LOD1 and LOD2 must be horizontal. The ground surfaces should, though, be determined per individual building and not per block of buildings. This surface is then positioned at the lowest height of the terrain at the location of this surface so that the building sinks “in” the terrain and gaps between ground surface are avoided, see Figure 2.

Requirement 16 The building height is the median of the height of the points which are positioned within the footprint.

Requirement 21 The geometry of LOD1 Buildings should be defined in CityGML as GML:Solids (closed volumes, also from

below) and not as GML:MultiSurface, which is permitted for LOD1 buildings.

Requirement 22 Each LOD2 IMGeo building is modeled by the GML:Solid geometry type in which the semantics of the boundaries (surfaces) are made explicit (e.g. footprint, roof surface, wall surface). LOD2 buildings can be represented as a collection of a solid with other geometry types such as a multisurface for a roof overhang.

Requirement 26 When a roof overhang is explicitly modeled, roof surfaces should be split at the roof overhang’s location to obtain a valid solid geometry. These roof overhangs should be modeled as a (multi)surface and the rest of the roof should form a part of the solid geometry’s boundary.

Requirement 27 LOD2 roof surfaces with a minimum surface area of X m2 may not deviate more than Y m in height from the corresponding points from the point cloud. This enforces a minimum detail level as well as a precision level of data modeling. Consequently an asymmetrical saddle roof is not modeled as symmetrical because then the deviations would be too high. By keeping the area limit high (for example 4 square meters) this enforces dormers only be modeled if they are large.

Requirement 28 Roof surfaces with a minimum surface area of X m2 may not deviate more than Y degrees in the normal direction from a surface because of the corresponding points from the point cloud. This prevents very flat saddle roofs to be modeled by flat roofs and mansard roofs to be modeled by saddle roofs.

Requirement 33 The 3D model must contain all the data necessary in order to give a complete and unambiguous relation between texture information and geometry.

Figure 2: A building “sinks” in the terrain because its lowest height at the terrain level is assigned to the horizontal

ground surface. (Figure from SIG3D (2013b))

3.1 LOD0 (2.5D) representations of 2D land use, water and road polygon objects Each 2D IMGeo polygon obtains its own LOD0 2.5D surface, represented by a TriangulatedSurface. This 2.5D surface per object is the result of a constrained triangulation (Shewchuk, 1997) of point heights with the 2D polygon boundaries as constraints. Consequently, the IMGeo object boundaries are represented as a (set of) triangle boundaries in the Triangulated Irregular Network (TIN). To reflect sufficient height, vertices can be added to the boundaries and height points should be represented within the original polygons. Requirements that enforce a correct LOD0 surface are 4 and 5. It should be noted that this concept does not require that the individual 2.5D surfaces per object are stored as such since this results in a lot of redundancy. Instead a TIN can be created covering the whole area in which the individual 2.5D surfaces are embedded. Requirement 5 is a known requirement from 2D: the representation at ground level should be a planar partition, i.e. there should be no holes or overlapping objects. Optionally, CityGML defines such topological requirement for the land use class. IMGeo-CityGML extends this principle to more classes, because the ground level (i.e. the skin of of the earth) consists of roads, water, buildings, vegetation, constructions etc. Since the CityGML specifications do not model LOD0 representations for all classes, we submitted a change request to OGC to model all CityGML classes also at LOD0. Specific attention should be paid to the fact that polygons that touch in 2D do not necessarily touch in 3D. For example, a curb causes the road and the pavement to be separated from each other by a vertical jump. For certain applications it is important to keep this height jump, for example to calculate the water streams during heavy rainfalls in city areas, see Figure 3. Requirements 7 and 8 provide guidelines of how to fill these "gaps".

Figure 3: Height jumps near curbs are important information for hydrological modeling

Apart from objects at the ground level, it is possible to model objects above and below ground in LOD0. These objects are modeled with a TriangulatedSurface in such a way that flyovers (Figure 4a) or underpasses (Figure 4b) are represented as such. By “stacking” two or more 2.5D surfaces, it is possible to have multiple z-values on the same x, y location (to model the under- and overpasses), which is not possible with a single 2.5D surface by definition (Tse and Gold, 2004).

Figure 4: Multi-level crossing (a, source: University of Twente) and underpasses (b, source: province of North-Brabant) represented as a collection of LOD0 surfaces.

3.2 Requirements for LOD0-LOD1-LOD2 buildings The specifications contain requirements for buildings at the different levels of detail.

LOD0-Building LOD0 buildings are represented with their footprints, i.e. the original IMGeo geometry, which describes the building boundaries at ground level. Also, roof edges of LOD0 buildings can be represented in LOD0. The geometry of the roof edge is often similar to the geometry maintained in the building register, i.e. the largest possible outline as shown from the top view (additional to the IMGeo footprint geometry, which may differ from the largest outline geometry). CityGML demands both LOD0 representations to be horizontal (i.e. with equal zvalues). Therefore buildings on a slope need additional polygons to make them fit in the surrounding terrain. However, since we consider this as suboptimal, we have submitted a change request to OGC to allow non-horizontal building footprints and roof edges in LOD0, while keeping the horizontal requirement for the ground surfaces of LOD1 and LOD2 buildings. Requirement 13 prescribes how height needs to be assigned to building footprints in a uniform way.

LOD1-Building LOD1 buildings are represented as blocks by extruding 2D building geometries using one height (Ledoux and Meijers, 2011). This can be the average of the point heights that fall within the polygon. However, often it is better to use the median to exclude the outliers near the edges (requirement 16). The extrusion results in a 3D geometry. Requirement 21 prescribes the use of a solid geometry type for this geometry. This is more restrictive than the CityGML-specifications, which also allow multi-surface geometries. A GML:Solid enforces the volume to be closed, in contrast to the multi-surface geometry type. We believe this to be useful for several applications, for instance the calculation of volumes for cadastral purposes.

LOD2-Building For the same reason, requirement 22 enforces that LOD2 representations of buildings be modeled with a solid geometry type, but the appropriate semantics must be attached to each surface of the solid, as Figure 5 shows. This can be useful in certain applications, for example

to assign different colors to the different faces (i.e. walls, ground and roof) or for calculating the solar potential of a house.

Figure 5: left: a solid without semantics attached to the LOD1 surfaces, right: LOD2 solid with associated surfaces modeled (source: SIG 3d, 2013b)

LOD2 roof shapes can be generated by different methods. Each method results in different types of deviations of the models compared to the actual shape of the buildings. Depending on the intended application the method should be chosen with the least disturbing deviation. Examples of such choices are the following.

How to connect to existing 2D geometry Usually, the location of the walls must match the building geometry in 2D. This ensures consistency between 3D and 2D representations of buildings. However, small errors in the 2D geometry may result in errors or deviations in the 3D model. See Figure 6. For example, when the geometry of a rectangular house with a gable roof is not exactly rectangular in 2D, the gutters in the 3D model will not run horizontally. It is possible to correct this in the 3D model, but one should be aware that the plane through the rooftop and roof gutter becomes curved or contains a bend. Both adjustments can be disturbing in visualizations. Such deviations can be avoided when the 2D geometry is adapted. Ideally, this is done in the 2D source and therefore the 3D model can be used to improve the quality of this information.

Figure 6: Laser data not matching building footprints make it hard to generate roofs consistent with the footprints

With or without roof overhangs To generate 3D building-geometries from 2D building-geometries, one can either use the IMGeo geometry (footprints) or the geometry maintained in the building and address register (largest extent from top-view). When these geometries do not match, a building with roof overhang can be modeled, see Figure 7. The CityGML specifications support both approaches, i.e. with and without roof overhang. Requirement 26 provides more details on the modeling of roof overhangs.

Figure 7: from left to right: Building with roof overhang in light grey, 3D building model based on 2D IMGeo geometry (wall location); 3D building model based on largest-extent geometry; 3D building model based on a combination of both geometries.

Use of standard roof shapes Some methods for reconstructing roof shapes use a library of standard roof shapes (Figure 8). This approach segments the points inside a 2D building geometry, so that a single and simple standard roof shape can model each part. Complex roof shapes are then built from a collection of simple roof shapes. The rate of success for complex (composite) roof shapes largely

depends on the extent to which the 2D building outline successfully can be partitioned. The advantage of this approach is that roof shapes can be modeled even with low resolutions of point heights (the alternative of fitting planes through laser data requires high resolution data). The disadvantage, however, is that roof shapes not in the library cannot be reconstructed. Combinations of more methods are possible. Therefore, the technical specifications do not prescribe a certain method, but only specify the requirements to be met by the reconstructed building models, see for example requirements 27 and 28.

Figure 8: Standard roof shapes (source: http://www.nachi.org/forum/f11/mitigation-roofshape-41293/)

4. AUTOMATED METHODOLOGY TO RECONSTRUCT 3D INFORMATION

After the definition of the implementation specifications for CityGML-IMGeo data, the next challenge is to generate 3D information compliant with the standard, preferably automatically. The automated generation of 3D objects from 3D raw input data (possible 3D sources are defined in the next section), has been studied by many researchers, e.g. Zhou and Neuman (2009) and Lafarge and Alliez (2013). To show how 3D objects can be generated according to our defined implementation specifications, we used the open-source tools of Oude Elberink and Vosselman (2009a; 2009b) and Oude Elberink et al (2013) and adjusted these to meet the 3D IMGeo requirements (see section 4.1). These 3D reconstruction tools generate 3D objects from highresolution Lidar data and 2D IMGeo data and are available at Geonovum (2013b). The tools in combination with the countrywide available 2D IMGeo data as well as high-resolution Lidar data (AHN2, see section 2) provide the basis for generating 3D IMGeo structured data

for the whole country for all object types. For the roofs of buildings, the method of fitting planes through height points is used, to assure consistency with the 2D footprints of the buildings. To make the open-source reconstruction tools accessible for the wide public and to structure the reconstructed 3D geometries according to IMGeo-CityGML, they have been embedded within a mainstream GIS software package, i.e. FME (www.safe.com). The FME workbench is described in section 4.2. Finally Section 4.3 describes how a 3D validation tool, which has been developed for this purpose, can check the quality of the output against the defined specifications. 4.1 Constructing 3D information according to the specifications The abovementioned open-source tools generate LOD0 representations for all IMGeo classes as well as LOD1 and LOD2 for both buildings and plant cover. The reconstruction is driven by rules that prescribe how to process the Lidar data, how to model specific object types, and how to connect neighboring objects in 3D. In LOD0, each polygon from the 2D source is represented by a triangulated surface, for which the height of the polygon boundary and the heights within the polygon are calculated from the lidar data. In a first step the height is calculated per node per polygon. As every node is on the boundary of at least two polygons (IMGeo forms a planar partition), multiple heights are calculated in this step. The height is either determined by fitting a plane through the nearby lidar points within each polygon or constrained by the semantic rules for specific classes, such as for water polygons (should always be horizontal). In a second step, it is decided whether the multiple heights at one location should be combined (“adjusted”) to one height or not. The first decision results in smoothly connected polygons; the latter results in a height jump between two polygons to keep for example subtle height jumps at curbstones between sidewalks and main roads, as shown for water management applications (see for example www.hydrocity.com). Finally, heights within polygons are calculated by triangulating the lidar points that fall within the polygon. How to model the height inside the

polygons also depends on the class of the polygon. Meadow fields for example may keep the height variation within the terrain. For water polygons it is undesired to have height variation at the boundaries but also within the polygon. Therefore semantic rules are applied to constrain the shape of the boundary and the inner structure of the 3D water polygons to be flat. For LOD1 and LOD2 representations of type “building” and “plant cover” vertical “walls” are generated that extrude these polygons downwards to the height of the Digital Terrain Model (DTM). In LOD2 these walls can obtain their own semantics. A ground polygon is calculated from underlying terrain to make the object solid. The upper surfaces (“roof surfaces” in case of buildings) in LOD2 are generated by a constrained triangulation of the heights that fall within the polygon. First, laser points within a polygon are segmented into planar patches. Patches larger than 2 square meters are considered as roof segments. Polygon boundaries and intersection lines between neighboring roof segments are taken as constraints in the triangulation. See Figure 1 for the result of LOD0 and LOD2 representations. The open-source tools can be called directly to automatically reconstruct all 3D IMGeo geometries from 2D IMGeo and laser data. In addition, the tools are included in an FME workbench to offer a user-friendly interface to the tools. In addition to 3D reconstruction, the FME workbench structures the data at the end of the construction process in 3D IMGeo (i.e. CityGML) compliant format. The processing time largely on how many polygons and boundaries between polygons are present in the source data. For an “average” area of 1x1 km with 200 polygons, the preprocessing time in FME was 10 minutes, the open source tools to reconstruct the 3D geometries require 40 minutes and the CityGML generation another 5 minutes. This is less than an 1 hour for a square kilometer. This seems significant, but the 3D reconstruction of a complete area needs to be done only once. A future update can be limited to specific objects or areas only. To process complete areas in reasonable time, we are currently testing a parallel cloud computing environment.

4.2 Implementation in FME A user-friendly layer on top of the open-source tools has been developed with FME. The process in the FME Workbench consists of three parts (see figure 9). The first FME Workspace receives user’s parameters, reads and checks source files, does necessary point-inpolygon operations, writes intermediate result files for further processing, and calls a Python script to start the next step of the process. The main part of the 3D construction calls the 3D IMGeo tools as described in the previous section. The final FME Workspace merges the files produced by the 3D IMGeo tools, adds the attributes and properties from 2D IMGeo and writes 3D IMGeo (i.e. CityGML) files.

Figure 9: The three parts of the automated FME-based workflow

Handling User parameters and checking incoming data When running the first FME Workspace, users can make several choices on incoming data and desired results. As input data the workspace expects a CityGML 2D IMGeo file as well as corresponding AHN2 file in a standard LAS/LAZ format. One can also specify an area of interest with a rectangular bounding box. In addition the user sets the desired results choosing between different levels of output detail, e.g. “LOD 0 Terrain” and/ or “LOD2 Buildings” and/or “LOD2 Plant Cover”. First, it has to be checked whether the polygons contained by the incoming CityGML IMGeo data are geometrically and topologically correct and on ground level only. The lidar data is also examined to make sure it is organized in accordance with the AHN standard. Moreover, the data is divided in ground and non-ground data for later processing. In a point-in-polygon operation, each laser point is assigned a corresponding polygon-ID number. As the large-scale

map may contain many donut shaped polygons, it needs to be carefully checked whether points fall inside a polygon or a hole inside that polygon. Finally, the lidar points are transferred to the 3D IMGeo tools.

Integrated Python script for calling 3D IMGeo tools Beside source data preparation, the first FME Workspace controls the overall process by automatically calling an integrated Python script. Depending on the user’s choice, the 3D IMGeo tools are called in a certain order with specific parameters. These tools do the main 3D generation work. After the completion of the 3D IMGeo tools the Python script calls the final FME Workspace

Final preparations and writing CityGML 3D IMGeo files The final FME Workspace reads the data from the 3D IMGeo tools. Since these data files are structured in a special topology-based format, appropriate internal FME objects (referred as FME Features) have to be constructed first and then merged with the original CityGML 2D IMGeo file to transfer attributes and properties. One key aspect of IMGeo (and CityGML in general) is the coherent modeling of semantics and geometrical/topological properties. Buildings, for example, may consist of Roof-, Wall-, and GroundSurfaces that are linked geometrically and topologically. The FME Workspace ensures that all features are described and merged correctly. Depending on the type of the feature, colors and CityGML specific geometry properties have to be added to guarantee appropriate CityGML object creation. For example, buildings can be produced with different levels of detail ranging from 0 (footprints) to 2 (with detailed roofs). This means that, within the workspace, different attributes (referred as Geometry Properties), like “lod0FootPrint”, “lod1Solid”, or “lod2Solid”, have to be assigned to the features. The coloring is based on the official ”IMGeo visualisation” and done individually for each feature depending of its type and associated attributes. Finally, all relevant feature types and their corresponding attributes are defined and

the CityGML 3D IMGeo file is produced. As for the technology, analogous to any other CityGML ADE, the IMGeo schema description (xsd-files) is used within the CityGML Reader and Writer to enable FME to read from and write data to the IMGeo schema.

4.3 Geometric validation of the resulting 3D models The constructed 3D objects can be geometrically validated with the 3D validator developed during the 3D Pilot. It has been made available as an open-source program, freely available at https://github.com/tudelft-gist/val3dity under an open-source licence.. The validation is performed against the definition of a solid given by the international standard ISO 19107 and implemented in GML specifications. During the first phase of the 3D Pilot, we realized that while several GIS software perform geometric validation of solids, they all use different definitions, and perhaps worse, none is fully compliant with the international standard. Instead, a simpler definition is often used, one where interior cavities and interior holes in surfaces are not allowed (Bogdahn and Coors, 2010; Wagner et al., 2013; Gröger and Plümer, 2011). The details of the validation process developed within the 3D Pilot are available in Ledoux (2013), but in brief the following assertions are verified: •

Solid boundaries form a closed object (it is “watertight”);

•

No intersections between the surfaces;

•

No duplicate points/surfaces;

•

Each surface forming a solid is a valid surface/polygon in 2D.

The validator was not only used to validate the output of the above-described methodology. It was also used during the development to ensure that the workflow produced correct output. Vice versa, the output of the workflow has permitted us to improve the validator and to identify, and fix, bugs. In addition, the development of the validator was important for the establishment of the requirements (described in Section 3), as these requirements are not only a wished list, but are also technically possible to implement. Therefore, specific attention was

paid to be able to evaluate the requirements by the validation tool, which improved both the specifications, and the validation tool. For example Requirement 21, where LOD1 buildings have to be defined as GML:Solids, is a direct result of the experiments made. Indeed, we often obtained building models defined as a set of GML:MultiSurface. It is possible to validate them as if they were a solid, but can we report an error to the user if a face is missing? During the 3D Pilot, we chose to report such a case with a warning that informs the user that some of the buildings were validated as if they were solids, and the validator warns them if the solid has errors. It also warns them that a given building, defined with GML:MultiSurfaces, is in fact a valid GML:Solid and should therefore be defined as such.

5. 3D SOURCE MATERIALS

For the reconstruction of 3D IMGeo information, the specifications advise to first structure the 2D information (i.e. 2D IMGeo) and then extend this data into 3D using various types of 3D source materials, i.e. 3D raw data. It is obvious that the 3D source material used to reconstruct 3D geo-information influences the quality of the results and therefore this is further explained in the implementation specifications. The most appropriate and often already available 3D source data are high-resolution laser data and (stereo) aerial photographs. In addition, organizations may already have acquired 3D source material for other purposes: laser scanning data from terrestrial dynamic acquisition, oblique aerial photos, 360° panoramic pictures or videos and point clouds from stereo aerial photographs via image matching . 5.1 Points Clouds from dense matching of aerial images 3D point clouds may also be generated from dense matching of aerial images. This becomes relevant in case of updates because aerial images are (usually) more frequently acquired than lidar data. With some limitations detailed, a highly accurate point clouds can be calculated from aerial images (Haala and Rothermel, 2012). Such a point cloud describes the "top view"

of the site (including objects), which is (almost) equal to the height data obtained from laser altimetry. The main requirements for the suitability of the images relate to the flight plan (a longitudinal overlap of at least 80% to assure the occurrence of each point in at least three images) and processing. The processing should obtain accurate orientation information. These requirements may impose additional requirements to those currently used to obtain aerial images for other purposes (e.g. to update 2D databases). The disadvantage of this method is that more than 10% of the points cannot be calculated because trees or other objects obscure them. Advantage of the method is that the aerial images are also suitable for the construction of texture information (Leberl et al., 2010). 5.3 How the 3D source material influences the resulting 3D information Although the intended use of the 3D geo-information should be the main drive for the quality level of the information, in practice often the available 3D source data determines the accuracy and precision of the 3D information that is produced. This is because costs for 3D reconstruction can be kept low, when already captured data is used. Table 2 shows which 3D details are in practice reconstructed from what 3D source material.

Table 2 : 3D source data that is used in practice to define certain 3D details of objects 3D details

Source 3D data

LOD1-Buildings

structured, 2D topographic data in combination with height data at a reasonable resolution (at least 1 point per square meter) obtained from high resolution laser data or from aerial photos

LOD2 properties up to roof

point clouds, at least 4 points per square meter

shapes, dormers and windows Textured buildings

images combined with accurate orientation information (aerial photographs with sufficient longitudinal and transverse overlap, oblique photographs or panoramas)

2.5D terrain (LOD0)

height point data at required density

LOD1/LOD2 trees and

high-resolution height data

vegetation

6. CONCLUSIONS AND FUTURE WORK

This paper has presented the best practices and recommendations for the production of 3D geo-information, starting from the OGC 3D standard “CityGML”. Although, based on our experience during the 3D Pilot NL, CityGML offers a solid base for 3D information modeling, it is also too flexible, which can cause ambiguity when modeling 3D geoinformation. A concrete example is a city in the Netherlands that outsourced their 3D data modeling, and asked for LOD2 data encoded in CityGML that they could use for spatial analyses. The models they obtained contained buildings stored with multi-surfaces, and some of the volumes were not closed. Although problematic for this specific city, it is not clear if the data was indeed what they asked for. This shows that we not only need more guidance for CityGML implementations, but also validation tools that check the quality of data against these guidelines. This is why the 3D Pilot experimented with test data and use-cases to find the best way for CityGML implementation to obtain high-quality and consistent 3D data for the whole of the Netherlands. The obtained insights led to refining and extending CityGML. This paper shows that the resulting specifications further explain the CityGML standard in situations where the standard is vague. In addition, they provide guidance in cases where CityGML allows flexibility, and that ensures an uniform implementation in the Netherlands. The paper also presents the workflow that we developed to automatically generate 3D information compliant with the specifications, as well as a 3D validation tool than can check if the specifications are met. The 3D pilot NL community has recently turned into a 3D Special Interest Group to address the still open 3D issues in collaboration with all stakeholders. Among these are agreeing on implementation guidelines for CityGML at the international level. A proposal for an OGC

Interoperability Experiment to define and validate data quality requirements of CityGML data in order to obtain clear implementation guidelines is currently under review at OGC. It is expected that the requirements will be further refined in a next version, when more people have built 3D information and have found new situations that need to be handled.

7. REFERENCES Becker, T., C. Nagel, and T.H. Kolbe, 2013. Semantic 3D Modeling of Multi-Utility Networks in Cities for Analysis and 3D Visualization. Progress and New Trends in 3D Geoinformation Sciences. Springer, pp. 41–62.

Benner, J., A. Geiger, G. Gröger, K. H. Häfele, and M.O. Löwner, 2013, Enhanced LOD concepts for virtual 3d city models. ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. II-2/W1, ISPRS 8th 3DGeoInfo Conference & WG II/2 Workshop, 27–29 November, Istanbul, Turkey.

Bogdahn, J. and V. Coors, 2010. Towards an automated Healing of 3D urban models. International Archives of Photogrammetry, Remote Sensing and Spatial Information Science, vol. XVIII, part 4/W15, pp. 13–17.

CityGML ADE, 2013. CityGML Application Domain Extensions. URL: www.citygmlwiki.org/index.php/CityGML-ADEs.

Czerwinski, A., T.H. Kolbe, L. Plümer, and E. Stöcker-Meier, 2006. Interoperability and accuracy requirements for EU environmental noise mapping. Proceedings Intercarto–Intergis 12, pp. 182-194.

Czerwinski, A., S. Sandmann, E. Stöcker-Meier, and L. Plümer, 2007. Sustainable SDI for EU noise mapping in NRW – best practice for INSPIRE. International Journal Spatial Data Infrastructures Research 2, 90–111.

Geonovum, 2013a. Technical specifications for the reconstruction of 3D IMGeo CityGML data, URL: http://www.geonovum.nl/sites/default/files/3DFinalReport_2013_1.01_0.pdf Geonovum, 2013b, FME Workbench and Open Source tools to automatically reconstruct 3D IMGeo data from high resolution laser data and 2D IMGeo data, URL: http://www.geonovum.nl/onderwerpen/3d-geo-informatie/documenten/bestand-workbenchand-3d-imgeo-tools-version-101.

Gröger, G., and L. Plümer, 2011. How to achieve consistency for 3D city models. Geoinformatica 15: 137–165.

Gröger, G. and L. Plümer, 2012, CityGML – Interoperable semantic 3D city models, ISPRS Journal of Photogrammetry and Remote Sensing, 71:12-33.

Haala, N. and M. Rothermel, 2012. Dense Multi-Stereo Matching for High Quality Digital Elevation Models. Photogrammetrie Fernerkundung Geoinformation 2012(4):331–343.

INSPIRE, 2013. D2.8.III.2 Data Specification on Buildings – Draft Technical Guidelines.

Lafarge, F. and Alliez, P. (2013). Surface reconstruction through point set structuring. Computer Graphics Forum, Wiley Online Library, 225-234.

Leberl, F., A. Irschara, T. Pock, P. Meixner, M. Gruber, S. Scholz, and A. Wiechert, 2010, Point Clouds: Lidar versus 3D Vision. Photogrammetric Engineering & Remote Sensing, 76(10):1123-1134.

Ledoux, H., 2013, On the validation of solids represented with the international standards for geographic information, Computer-Aided Civil and Infrastructure Engineering, 28(9):693706.

Ledoux, H. and Meijers, B.M., 2012. Topologically consistent 3D city models obtained by extrusion. International Journal of Geographical Information Science, 25(4):557–574.

OCG, 2012. City Geography Markup Language (CityGML) Encoding Standard, version 2.0.

Oude Elberink, S., J. Stoter, H. Ledoux, T. Commandeur, 2013. Generation and Dissemination of a National Virtual 3D City and Landscape Model for the Netherlands, Photogrammetric Engineering & Remote Sensing, 79(2):147-158.

Oude Elberink, S.J. and G. Vosselman, 2009a. 3D information extraction from laser point clouds covering complex road junctions. The Photogrammetric Record. 24(125):23-36.

Oude Elberink, S.J. and G. Vosselman, 2009b. Building reconstruction by target based graph matching on incomplete laser data: analysis and limitations. Sensors 9(8):6101–6118.

Portele, C., 2009. OGC® OWS-6 UTDS-CityGML Implementation Profile.

Shewchuk, J., 1997, Delaunay Refinement Mesh Generation, Ph.D. thesis, Technical Report CMU-CS-97-137, School of Computer Science, Carnegie Mellon University, Pittsburgh, Pennsylvania, 18 May 1997.

SIG 3D (2013a). Teil 1: "Grundlagen - Regeln für valide GML Geometrie-Elemente in CityGML": URL: http://wiki.quality.sig3d.org/index.php/Handbuch_für_die_Modellierung_von_3D_Objekten_ -_Teil_1:_Grundlagen_(Regeln_für_valide_GML_Geometrie-Elemente_in_CityGML).

SIG 3D (2013b) Teil 2: "Modellierungshandbuch Gebäude (LoD1, LoD2, LoD3)": URL: http://wiki.quality.sig3d.org/index.php/Handbuch_für_die_Modellierung_von _3D_Objekten_-_Teil_2:_Modellierung_Gebäude_(LOD1,_LOD2_und_LOD3).

Stoter, J., H. Ledoux, M. Reuvers, L. van den Brink, R. Klooster, P. Janssen, J. Beetz, F. Penninga, and G. Vosselman, 2013. Establishing and implementing a national 3D standard in the Netherlands. Photogrammetrie Fernerkundung Geoinformation (PFG), 2013(4):381-392.

Stoter, J., G. Vosselman, J. Goos, S. Zlatanova, E. Verbree, R. Klooster, and M. Reuvers, 2011. Towards a National 3D Spatial Data Infrastructure: Case of The Netherlands. Photogrammetrie Fernerkundung Geoinformation (PFG) 2011(6):405–420.

Tse, R. O. C. and Gold, C. M., 2004. TIN meets CAD—extending the TIN concept in GIS. Future Generation Computer Systems, 20(7):1171–1184.

Van den Brink L., J.E. Stoter, and S. Zlatanova (2012). Modeling an application domain extension of CityGML in UML, OGC best practice paper: URL: https://portal.opengeospatial.org/files/?artifact_id=49000.

Van den Brink L., J. Stoter, and S. Zlatanova, 2013a. Establishing a national standard for 3D topographic data compliant to CityGML, International Journal of Geographical Information Science, 27(1):92-113.

Van den Brink L., J.E. Stoter, and S. Zlatanova, 2013b. UML-based approach to developing a CityGML application domain extension, Transactions in GIS, in press.

Wagner, D., M. Wewetzer, J. Bogdahn, N. Alam, M. Pries and V. Coors, 2013. GeometricSemantical Consistency Validation of CityGML Models. Progress and New Trends in 3D Geoinformation Sciences, Pouliot, J., Daniel, S., Hubert, F., Zamyadi, A., editors, Lecture Notes in Geoinformation and Cartography. Springer Berlin Heidelberg, pp. 171–192

Zhou, Q. and Neumann, U. (2011). 2.5 D building modeling with topology control. Proceedings IEEE Computer Society Conference on Computer Vision and Pattern Recognition (CVPR'11), Colorado Springs, USA, 2489-2496.