IFCTERRAIN – A FREE AND OPEN SOURCE TOOL TO CONVERT DIGITAL TERRAIN MODELS (DTM) TO OPENBIM INDUSTRY FOUNDATION CLASSES (IFC)

: Digital Terrain Models (DTM) play an important role for digital twins of the built environment. However, if the Building Information Modeling method (BIM) is used, many engineers find it difficult to provide BIM-compliant terrain models. We present a small tool with which classic DTM, which have been created by landsurveyors or geospatial engineers, can be converted into the format Industry Foundation Classes (IFC) in order to be used in openBIM projects. This paper first clarifies the use cases and then goes into detail on possible configurations of the transformation process. With the presented software tool IfcTerrain the user may select different export options concerning IFC object type of the terrain, geometric representation, georeferencing or the annotation with metadata. IfcTerrain is free and open source and was developed in the context of an educational institution.


INTRODUCTION AND MOTIVATION
With the open source software IfcTerrain, we present a specialized Extract-Transform-Load (ETL) tool for creating digital terrain models (DTM) using the Industry Foundation Classes (IFC) for openBIM projects. The software tool can convert many standard formats and model representations of DTM. Users can configure the IFC output with regard to IFC version and schema, the object representation, type of georeferencing and additional metadata. The .Net stand-alone software IfcTerrain can be executed as a command line application (cmd) for batch processing or with a graphical user interface (GUI) on Windows. The software is published as sub-module in the GitHub Repository CityBIM (DD-BIM Development Team, 2021) with GPL-3.0 License.
Earth mass calculation and terrain modeling are of central importance for the design, implementation planning and construction in structural-, civil-, water-and transport engineering. Nevertheless, engineering services related to the terrain are carried out as a digitally separated sub-task at the current state of professional practice. When the model is transferred, a model conversion must take place so that the DTM can also be used collaboratively in openBIM projects. This necessity was formulated by our regional practice network "DD-BIM", made up for land surveyors, civil engineers, project developers, who want to advance the openBIM method in their professional practice. This has to be mentioned because some of the DTM data formats that are converted by IfcTerrrain are only used on national level in Germany.
In addition, we have further developed the converter for the "TerrainTwin" research project. In this project, virtual landscape planning processes are made BIM-capable and the open source software IfcTerrain presented in this paper is used in the back end for a commercial VR/ARsoftware for geospatial planning of wind turbines.
With IfcTerrain, small and medium-sized engineering offices can adapt their information delivery for BIM pro-  (Romanschek et al., 2019) jects without having to make major changes to the data acquisition and modeling procedures. IfcTerrain is a pure converter and does not replace the geospatial specialist software for creating and checking digital terrain models. On the other hand, BIM authoring software and BIM common data environments (CDE) do not support all DTM model types and formats that are normally provided by geospatial engineers. In addition, BIM systems are not always able to process geo-referenced data and (2.5D) surface geometries.
The focus of this "applied sciences" paper is on the following research question: • Which IFC concepts must be selectable during the conversion of DTMs for openBIM projects?
In addition, we try to answer the following sub-questions in the course of the investigation: • Which use cases for DTM are relevant for BIM projects?
• Which input types and formats of DTM must be transformed by the converter?
• How can the software be developed as simply as possible in the context of academic institutions?
We believe that IfcTerrain confirms to the buildingS-MART goal which is to enable full support of "openBIM". As postulated in (buildingSMART International, 2020) the basic principles of openBIM are: (1) Interoperability, (2) open and neutral standards, (3) reliable data exchanges, (4) collaboration, (5) flexibility in the choice of technology and (6) sustainability.
In our case, the general objectives (1) interoperability and (4) collaboration relate to both the actual data of the terrain model and the interaction between the geospatial and BIM domains. The goals (2) open standard and (6) sustainability are evidently achieved through the central usage of the IFC in our research project. The (3) reliability is achieved in our software through extensive (verbose) logging as well by the many configuration options with regard to the IFC concepts. This optionality enables the IFC export to be precisely adapted to the target BIM software.
A vicinity model (Clemen et al., 2021) in general is the digital twin of the built environment, representing the existing situation of the surroundings of a planned building. It creates the basis for spatial understanding, planning, construction and maintenance. In addition to city model, utilities model, cadastral model, spatial planning zoning model, the digital terrain model (DTM) forms the basis for many use cases in BIM projects. Regardless of the form type, the DTM has the following main content: • Points (single or line points or points of triangles) maybe connected in an implicit (raster) or explicit (TIN) topological structure.
• Lines to delimit the area to be modelled (ring, holes) • Breaklines, i.e. lines to distinguish between terrain sections with different slopes Digital terrain models (DTM) are geospatial standard products. Despite its supposed simplicity, a DTM can have very variable properties that are for example listed in (DIN18740-6, 2014). These include: • up-to-dateness; • horizontal and vertical coordinate reference system; • mathematical representation and data structure (grid, TIN, mathematical surface modeling, interpolation rule, etc.); • form of representation (elevation points, contour lines, color-coded representation ...); • acquisition methods and measurement accuracy and original point distribution; • internal and external accuracy of the derived / preprocessed DTM, type and number of sub-areas and object areas; • data gaps and links with other data sets; • type and number of structural elements (break line, slope, recess area, ...); • treatment of water surfaces; • fitting of engineering structures (bridge, tunnel) and natural overhangs that require separate modeling.
This list shows that digital terrain models are more complex than one might think. That is why they should be created, managed and published in BIM projects by geospatial experts. IfcTerrain can support the specialist here. In our research we identified four openBIM data exchange scenarios, where IfcTerrain can help to deliver the DTM as IFC Model: 1. Transfer DTM from surveying software to BIM authoring systems. Here the DTM serves as digitization reference and basis for planning; 2. Transfer DTM directly to the BIM common data environment (CDE), which is a workflow and collaboration tool for the BIM coordination model. Here the DTM is used for visualization, collision analysis or quality assurance; 3. Transfer from BIM to GIS or to surveying CAD.
Here the DTM from the BIM Software is used for landscape planing, stake out or specific tasks of land management.

Linked payload in Information Container for Linked
Data Deliveries, known as ICDD (ISO21597, 2020-04), e.g. to link a DTM with specifications for tendering.
Until now, the IfcTerrain tool may be used to transfer DTM in user scenarios (1) and (2). The backward converter (IFC to GIS/CAD)) is currently not planed, whereas the link models (4) are currently under investigation, but not a topic of this paper.

RELATED WORK
Mathematical operations with DTM have been academically discussed since many years (Zevenbergen and Thorne, 1987). Also the integration of DTM with geospatial objects in CAD software has been continuously investigated by geospatial research, e.g. (Zlatanova et al., 1996).
An up-to-date and didactically very well-presented overview is the "Terrainbook" (Ledoux et al., 2021): It provides all the conceptual and mathematical basics for digital terrain models, such as the grid and Triangulated Irregular Network (TIN). Also Delaunay Triangulation and the Voronoi Diagram are taken up from the point of view of programming. They also explain the conversion between the various terrain presentations, such as point cloud, grid, TIN and contour lines.
The most relevant technical report for our research is "IFC Infra Overall Architecture Project Documentation and Guidelines" (Borrmann et al., 2017). They provide special modeling guidelines that go beyond the information that is published in the IFC standard document. For example, the types of geometric and topological representation of terrain models in IFC are discussed in detail.
In the following sections we analyze how a DTM can be described by means of the IFC standards. The requirements of various application areas and users should be considered here. Accordingly, the two standardized schemes used for IfcTerrain are: Please note, that the calculation of the intersection curve between building and terrain, as recently described in (Yan et al., 2019), is not part of the IfcTerrain tool.

CHOSEN CONCEPTS OF THE IFC STANDARD
In this section we describe how a DTM can be described by means of the IFC standards. The IfcTerrain converter offers the user a number of options to configure the IFC export. The selection concerns (section 3.1) the type of object formation, (section 3.2) the type of geometric representation of the terrain (section 3.3) the georeferencing and (3.4) the annotation with metadata. The user must make the selection with regard to the application and target software.

Terrain as BIM object
BIM is object-structured per se. As shown in figure 2, we have decided to offer two variants in order to integrate the terrain into the IFC concepts for structured object. The widely used but somewhat inappropriate variant is to provide an IfcSite object with geometry. This is illogical because IfcSite is not an actual object, but an IfcSpatialStructureElement, thus IfcSite should actually be used for the topological breakdown structure of the project. Nevertheless, it makes sense to export this variant for purely pragmatic reasons, as it can be interpreted and displayed by most BIM software. The better second variant uses IfcGeographicElement (see figure 2, right), which was introduced with IFC 4. Now it is possible to conceptualize the object representation and the spatial structure of the terrain separately. It is to be expected that further classes will be derived from IfcGeographicElement in future IFC versions and that the type enumeration (metadatum) will be extended.

Geometric representation of the terrain
With IfcTerrain the shape of a terrain can be described in three different ways ( figure 3 and 4). To link an object with its geometric representation, the entity Ifc-ShapeRepresentation is used. In the IFC 2x3 scheme, this can be done very easy by using IfcGeometricCurve-Set or more complex with IfcShellBasedSurfaceModel.
IfcGeometricCurveSet can be used to enable the data exchange of 2D or 3D points and curves. A DTM can thus be represented by means of the corresponding number of entities in the IfcPolyline. This enables the storage of both raster data sets and TIN, where each edge of a raster or triangle is described by an IfcPolyline. As a result, the DTM loses its topological structure, but -and that is the goal -BIM software can interpret it.
Another option for storing terrain information is the Ifc-ShellBasedSurfaceModel, which specifies open and closed shells. The closed shells listed here are actually used to store solid objects (e.g. columns). Thus open shells should always be used with regard to DTM, as these do not form a closed body. Thus, a DTM can be modeled using the appropriate number of entities (IfcFaces). This representation is particularly good if the TIN has already been generated by high-quality geospatial software. With this variant, the topological structure is also retained in the IFC. But the storage is highly redundant: Each Ifc-CartesianPoint is stored as resource by its own.  This is why the IfcTriangulatedFaceSet was introduced in IFC 4. Now a list for all coordinates used in the terrain model can be collected in IfcCartesianPointList3D and be used by the faces/triangles by index. In addition, IfcTriangulatedFaceSet can save the normal of each triangle.
With IFC 4.3 the concept of IfcIrregularTriangulatedNetwork is introduced to the standard. The main advantage of this new type is the ability to distinguish between visibility and breakline vs. no breakline for each side of a triangle. The type IfcIrregularTriangulatedNetwork is not implemented in our IfcTerrain tool yet.

Georeferencing
IfcTerrain offers the possibility of exporting different IFC approaches to georeferenc the terrain. When selecting the IFC concepts and designing the GUI, we are guided by the classification "Level of Georeferencing" (LoGeoRef), (Clemen and Görne, 2019). Here, five levels (LoGeoRef: 10, 20, 30, 40 and 50) for georeferencing within an IFC file are specified. Figure 5 gives a simplified overview on the level-concept. The higher the level, the higher the qualitative added value. However, as always in BIM projects, the capability of the target software must be carefully considered.
With the help of LoGeoRef 30, georeferencing can be expanded to include a project coordinate origin and a rotation. By placing the IfcSite, a 3 + 1-parameter transformation is implemented for horizontal translation, rotation around z-axis and elevation. This LoGeoRef is currently still expected by many software, although it is actually conceptually wrong: Because IfcSite does not represent an object, but a spatial structure and the terrain should not be placed in the "inertial system", having no reference to nothing.

IfcGeometric RepresentationContext
True North Conceptually more adequate -but only implemented by some software solutions -is LoGeoRef 40. LoGeoRef 40 uses the entity IfcGeometricRepresentationContext, which creates a well-defined coordinate system in IfcProject. It may be referenced by all building components and also by the terrain. As can be seen in figure 5, a link to IfcProject is created using IfcGeometricRepresentation-Context. In addition, the elements for georeferencing can be reused via the entity IfcAxis2Placement3D. However, the information is expanded to include the entity "Ifc-Direction (True North)". Thus there is the possibility to rotate the project against "true north". This means that projects can be rotated. Since this would represent a contradiction, level 30 and level 40 cannot be implemented at the same time.
The best, and hopefully future standard variant in all BIM software is LoGeoRef 50. An IFC model with LoGeoRef 50 represents the highest quality georeferencing. The concepts for georeferencing are included in the IFC 4 standard, but can also be transported in the IFC 2x3 schema via IfcPropertySets (buildingSMART Australasia, 2020). With the IfcMapConversion link between an IfcGeometricRepresentationContext and an IfcProjec-tedCRS, georeferencing can be comprehensively calculated by both, BIM and geospatial software. For large, elongated structures, more comprehensive geodetic assessments may have to be made. For this, (Jaud et al., 2020) provide a very good overview.

Semantic annotation of the terrain
If one understands BIM as "information management", metadata play a decisive role. These are standardized in (ISO19650-1, 2020), for example. Due to the wishes of our practice partners, however, we have oriented us for the national guidelines for BIM metadata and geodata: (DIN91391-1, 2019) specifies metadata that must be kept in an information container in a common data environment (CDE): This set of metadata is very generic and suitable for any file/object that is shared on the CDE. The more DTMspecific set of metadata of (DIN18740-6, 2014) is used for the technical annotation of the DTM. The metadata can be included in the conversion in different ways. They can be exported within the IFC file as IfcPropertySet or as a separate file (* .json). The separate JSON file may be used in system architectures, that use an unstructured object storage architecture. In this scenario the IFC file is the data object and the lightweight JSON file is used to transfer the metadata to the database management system.

RESULTS AND VALIDATION
The software has been tested in practical use by our practice partners and numerous students. In the following, the graphical user interface (GUI) and the import formats implemented up to now are briefly presented.

Graphical user interface (GUI)
In addition to the command line, which is started by a simple program call and JSON configuration file, a graphical user interface is available. The GUI, shown in figure 6 was implemented with the Windows Presentation Foundation (WPF). The GUI is basically divided into two columns. The left side is used to configure the input and the right side to set the IFC export type.
Because the software was developed in the context of an educational institution, we attached particular importance to detailed (verbose) logging. (1) input file format selection, (2) format specific import settings, (3) quick input information panel, (4) IFC export version, (5) concept for shape representation, (6) concept for georeferencing, (7) metadata and IfcProject settings (8) logging and verbosity level

Import formats
The basis for the practical success of the software Ifc-Terrain lies in the ability to read and import in a large number of different data formats and data models for terrain modeling. In the following, the import formats are described in brief.
LandXML Standard for exchange semantic models of DTM, Includes TIN and break lines as objects; CityGML Beside Buildings (LOD1-LOD4) the city model may also include the terrain as TIN, which is exclusively imported to IfcTerrain. Maybe additional intersection lines are part of the city model (see (Yan et al., 2019)), but these are not read by IfcTerrain until now; CAD/DXF Many terrain models are still delivered in the semantic-free drawing exchange format DXF. Because neither the semantics of the layers nor the type of geometry presentation are specified in DXF, the user has to make some settings during the import. The layer for points & lines or 3DFaces must be selected, also a specific layer for break lines can be specified; GRID An xyz-grid is the simplest data structure for DTM. The xyz-grid is transformed to a topological data structure for IFC, to avoid very large IFC Files, the area can be clipped. Nevertheless, when exporting, it must be ensured that BIM software is usually not able to process large terrain models with a large amount of points/triangles.  With the FZK-Viewer it was possible to ensure that the features presented in section 3.1 to 3.4 were actually transformed and exported in conformity with the standards, interpretable and technically meaningful. Figure 7 shows the export of a CityGML sample dataset (13MB). The file size with the different export options is 9MB (IfcGeometricCurveSet), 7.5MB (IfcShellBased-SurfaceModel), 4MB ( IfcTriangulatedFaceSet)

Validation with BIM software
The software must be technically correct and accessible. In addition, the user must be supported by understandable manuals or wiki. Among other things, these instructions must give specific information about which IFC export configuration is suitable for which target software (BIM). This is a fundamental problem for the IFC. The standard is very comprehensive and can only be partially implemented by the software companies. Therefore the project specification "use IFC" is not sufficient. In addition, modeling guidelines must be coordinated. The software used in the project must always be checked for its IFC suitability. Figure 8. Overview of the test results. The different BIM viewers, BIM authoring systems and BIM collaboration platforms handle the exported geometry types differently As shown in figure 8 the different schema (STEP, XML) and geometric representations, IfcGeometricCurveSet (IfcGCS), IfcShellBasedSurfaceModel (IfcSBSM) and IfcTriangulatedFaceSet (IfcTFS) where checked with many software products. If terrain models can be imported to the target BIM software, the question arises whether the terrain is classified semantically correctly as topography. For BIM projects it is particularly important whether the DTM can only be selected as a block or whether individual elements can also be edited.
The tests have to be continued continuously because, on the one hand, we are constantly improving our software and, on the other hand, the target software is also updated frequently. Because the integration of BIM and geospatial plays such an important role for the success of a BIM project, the target software should have an even higher update cycle in the future.

LIMITATIONS AND OUTLOOK
The requirements for IfcTerrain were drawn up by practitioners who would like to incorporate their digital terrain models into BIM projects.
IfcTerrain was initially developed as a standalone software for workstation computers (PC) so that it can also be easily used in smaller surveying offices. The future aim is to also offer the functionality as a web service (HTML and REST). At the conceptual level, IFC 4.3 If-cIrregularTriangulatedNetwork should be implementedas soon the underlying .Net open source library XBIM (Lockley et al., 2017) supports this possibility and the IFC 4.3 standard is finally published. In addition, it should also be possible to export partial sections of the terrain, for example on the basis of given polygons.
We hope that with IfcTerrain we were able to make a small contribution to the practical interoperability of geospatial data and digital building models and we look forward to tests and reports on our little tool.