Keywords

1 Introduction

Digital building models, mainly in the form of IFC (Industry Foundation Classes) data sets, are increasingly used as sources to complement or inform geospatial data sets, in particular city models. This poses the requirement to spatially locate building models in the geospatial context.

Georeferencing in IFC has also received extended attention during the last years due to the expanding scope of the standard beyond buildings into the area of large-scale infrastructure buildings such as roads and railways. The increased requirements where addressed in the update from ISO 16739:2005 and ISO 16739-1:2018 towards IFC4 (ISO 2018) with additional entities and attributes.Footnote 1 Experts from the GIS and surveying area have pointed out the insufficiencies and contributed to the developments. For example Jaud et al. (2020; 2022) provided comprehensive reviews on the necessity and details of improved georeferencing capability in IFC. Markic et al. (2018) demonstrate the deficiencies of early IFC georeferencing capabilities for infrastructure projects with two example projects, a long tunnel and a rail track.

In this paper, we present a case study on transferring georeference during conversion from IFC to OpenStreetMap (OSM). First, we provide a condensed overview of how IFC2x3 and IFC4 relate coordinates in local engineering coordinate systems to geospatial reference systems with examples for different constellations (Sect. 3). Second, we demonstrate a simple method to enrich IFC datasets with georeferences using existing OpenStreetMap outlines (Sect. 4). In the third part we describe two substantially different methods to convert engineering coordinates into geospatial coordinates and show how these methods are implemented in two open source software packages (Sect. 5). Finally, we verify and compare the methods with a set of sample IFC and OSM data (Sect. 6).

As the concepts are transferable to other geospatial formats, the results are interesting beyond OSM. Complementing the existing literature, this paper can serve as a practical guide for the community operating at the BIM-GIS intersection to create their own georeferenced data, to consume existing georeferenced data, and to avoid common pitfalls.

2 Related Work, Sample Data and Software

In this section, we put our study into context by reporting the state of the art and related work, listing the sample data used and the software implementations considered.

2.1 Related Work

Clemen and Görne (2019) have proposed a classification of different levels of georeferencing in IFC. They also provide a checking tool.Footnote 2 A correspoding tool for enrichment (IfcGeoRefUpdater) has been discontinued and is not maintained anymore.

Diakite et al. (2020) try to derive geolocation information by matching building outlines from digital building models against the corresponding building footprints or vertical projections from official land surveying data with OpenStreeMap data as a fallback.

Zhu et al. (2021) try to “verify” geolocation by displaying them in ArcGIS online, Google Earth, FME and their own software stack OCCT-OSA. They use the KIT samples for verification neglecting that two of the buildings are fantasy buildings.

Ohori et al. (2018) present a case study with georeferences being one facet. They describe the process to add georeferences with Revit 2018 and demonstrate an application to enrich the IFC site WGS84 geospatial position.Footnote 3 This tool does not handle rotation via true north though.

Some authors convert IFC for large scale display in geospatial context, but do not mention georeference at all, e.g. Chen et al. (2018) discuss conversion to GLTF and Cesium tiles using the Opensource BIMserver (Chen et al. 2018).

The GeoBIM benchmark 2019 led by Francesca Noardo was an investigation of the software landscape around processing digital building models in buildingSMART IFC and 3D city models in OGC CityGML. Among others facets, Noardo et al. report on the georeferencing capabilities of the probed tools, both in reading (interpreting) and writing (creating) georeference information and transforming it between the two formats (Noardo et al. 2020).

The user guide of Mitchell et al. (2020) provides guidelines for a standardized setting up of georeferenced BIM models using the IFC format. Besides general concepts and calculation rules of georeferencing, two main embedding methods are shown for storing georeferencing data in IFC2x3 via property sets and IFC4 via IFC entities (Mitchell et al. 2020).

2.2 Sample Projects

We are using a set of seven different projects and their respective digital building models in IFC (Industry Foundation classes) format, many of which are publicly available. Of all the projects, we use an IFC4 version—either directly as available or converted from an IFC2x3 version. Model A contains a public administration building under construction. Model B (Smiley West) and C (FZK house) stem from the famous KIT dataset. Model D is taken from the well-known Schependomlaan dataset, a Dutch semi-detached house. Model E is a Dutch sports hall, published by buildingSMART to demonstrate georeferencing in IFC4. Model F is a two-storey residential building, hand-crafted for testing purposes. Model G finally is a university library building with detailed information about interior equipment, such as book shelfs, desks and co-working spaces.

The projects deliberately differ with regard to the IFC version, originating software, georeferencing information, structure and other content of the building models. See Table 1 for the main properties of each model. In column 4, we provide the number of entities as an indication of the size. Column 3 records the IFC and column 7 the georeference version (see Sect. 3 for more detail). In column 6 we noted whether we found no (−), deficiant (o) or full (+) georeferencing information. Column 8 holds the length unit used for the geometry.

Table 1 Sample models with specific properties
Full size table

2.3 Software Implementations

The conversion algorithms described in Sect. 5 can be found in two different open source software applications. Both are implemented in Java and support the conversion of IFC to OSM as one part of a larger scope of functionality. In the course of conducting the case study, we were able to improve the software and consider the extraction of a shared library.

2.3.1 JOSM Indoorhelper

The first one is the Indoorhelper pluginFootnote 4 for the JOSM editorFootnote 5 which includes functionality to import IFC files and convert them to the Simple Indoor Tagging (SIT) Scheme.Footnote 6 The Indoorhelper was developed to exploit additional indoor data sources for OSM and ensure that the imported data is compliant to the standardised indoor modelling scheme.

2.3.2 LevelOut Platform

The second one is LevelOut,Footnote 7 a platform to convert building models in IFC format into various formats for map and navigation services, OSM (SIT) among others. The platform is based on the Opensource BIMserver and the conversion implemented as a BIMserver serializer plugin. The conversion is a two-step process, where an intermediate model holds all information extracted from the IFC and necessary to supply all target formats with the required input, including georeferencing information (Krishnakumar and Tauscher 2023).

3 Georeferencing Information in IFC

3.1 IFC Schema for Georeferencing Information

Georeferencing information can be represented in IFC with different depths and detail. The documentation of IFC4 (ISO 2018) contains fundamental concepts and assumptions about the project context. Thus, all project-related data sets have an instance of IfcProject that provides information about the overall context and a directory with including objects. The context definition contains the concept of global positioning of the project coordinate system for localization on the earth’s surface. For this purpose, information is usually indicated by values for the easting, northing, elevation, geodetic datum, vertical datum, and orientation. This part of the context definition shows how a spatial coordinate reference from recognized coordinate reference systems can be added to the context of the geometric representation. Thereby, the geometric representation context of the shape representation builds an additional context definition. For this reason, information will be specified about the coordinate system orientation, true north direction, precision, as well as further information that applies to all project-related geometries. This is realized with a main geometric representation context for 3D models and 2D representations that can be extended by geometric representation sub contexts.

Based on the mentioned concepts, we are distinguishing two configurations, the improved version from IFC4 and the outdated version from IFC2x3 as a fallback for legacy data. Following the attempt made by Clemen and Görne (2019) to classify geoinformation in IFC into so-called Levels of Georeferencing (LoGeoRef), these correspond to LoGeoRef50 or a combination of LoGeoRef40 and LoGeoRef20. In the following, we call these the “IFC4 style” and the “IFC2x3 style”. IFC4 accommodates both styles, and IFC2x3 only the last style. IFC2x3 style georeferences always pertain to the geodetic system WGS84, while IFC 4 style georeferences can pertain to any coordinate reference system (CRS), including WGS84.

About the templates of the fundamental concepts and assumptions from the IFC4 specification, the following figures represent an extraction of IFC entities and attributes for each style. The figures follow the notation of instance diagrams as used within the IFC4 documentation for the sake of clarity. In addition, the required IFC attributes are highlighted in blue font of the respective IFC entity. Figure 1 shows the extraction for the “IFC4 style”, while Fig. 2 shows the extraction for the “IFC2x3 style”.

Fig. 1
figure 1

Required IFC entities and attributes (blue) for “IFC4 style”, modified image

Full size image
Fig. 2
figure 2

Required IFC entities and attributes (blue) for “IFC2x3 style”, modified image

Full size image

3.2 Georeferencing Examples in SPF

In the following, we show examples and discuss the encountered population of the georeferencing concepts as occurring in the sample data of Sect. 2.2.

Listing 1.1 shows the georeferencing information for project E, Gymzaal Amersfoort as an example of IFC4 style georeferences. This sample had been published by buildingSMART to demonstrate IFC4 georeferencing capabilities and document CAD export procedures. The location was specified roughly and exported with Autodesk Revit. We show the corrected and enhanced version, for details on correction and enhancement see Sect. 4.

figure a

Similar to this, project A, public administration, contains IFC4 style information. The proper export from CAD is described in Sect. 3.3.

Below listing 1.2 shows the georeferencing information for project B, Smiley West from the well-known KIT sample data set, as an example for IFC2x3 style georeferences. This is the only sample in the list which contained proper georeferences out of the box.

figure b

Similar to this, projects C, D, F and G contain IFC2x3 style information, even though some of them are actually IFC4 files. For projects D and G we found the georeference pertaining to a default location in the respective region, e.g. Schependomlaan (D) in the Netherlands, university library (G) in central Berlin. For project abc, georeference information was missing altogether. A method to enrich and correct the georeferencing information is shown in Sect. 4.

3.3 Export from CAD

For new models, the preferred method of georeferencing in IFC models is provided by the “IFC4 style” with the highest quality in terms of georeferencing information available within an SPF file. Support for “IFC4 style” georeferences has only been added recently to CAD software because the entities and attributes necessary for this style were unavailable for previous IFC specifications, according to the implementation in software and certification processes.

Besides different BIM-enabled CAD software of the AEC (Architecture, Engineering, and Construction) industry, Autodesk Revit is a known representative for planning processes. Revit provides the SPF files export using an IFC exporter in a standard version or an externally installable open-source version. If the IFC export settings remain unconsidered, the “IFC2x3 style” is supported by default in case of available Revit data for the respective instances, leaving further data assignment settings unaffected. Furthermore, Revit’s IFC exporter supports the “IFC4 style” with specific geographic reference settings. For this purpose, an appropriate EPSG (European Petroleum Survey Group Geodesy) code and the coordinate base must be indicated. The EPSG code is used for accessing information about the coordinate reference system. The coordinate base is defined by using a Revit-specific coordinate base point, such as the project base point.

For example, project A, public administration, has been created using Autodesk Revit. The predefined MVD IFC4 Reference View [Architecture] has been used for generating an SPF file. The EPSG code 25833 has been specified because the project base point contains UTM coordinates that are located in a specific UTM zone.

4 IFC Enrichment

Where the information necessary for georeferencing (as described in Sect. 3) is not available, we enrich the IFC data, either by re-exporting with adjusted CAD settings (Sect. 3.3) or preferably with direct editing of the IFC-SPF (STEP physical file, a human-readable text file). In this section, following the elaboration of georeferencing concepts in IFC2x3 or IFC4 style, we describe a method to obtain the parameters for the population of the concept’s attributes from OSM building outlines. This way, the engineering CRS is positioned in WGS84, which can be written in either of the styles. If professional surveyor’s or cadastral reference information is available pertaining to other reference systems, then this should be used with priority and must be written in IFC4 style. Often though, this is not available, particularly for existing data stocks that should be retroactively integrated at the geospatial scale for management, navigation, analysis or other ubiquitous purposes.

This section provides a reusable method to enrich IFC with georeferencing information. We also contribute enriched data to the public domain.

4.1 Existing Georeferencing Information and Actual Location

First, we reviewed the existing georeferencing information in the files and gathered information about the actual location of the buildings.

Project A, the public administration, was enriched with surveyor’s information in IFC4 style.

Project B, Smiley West, has a correct IFC2x3 style georeference, corresponding to the address contained in the model. However, the IFC 4 version as published by KITFootnote 8 is not valid against IFC4 ADD2 TC1. The file, exported from ArchiCAD20, contains numerous entities of type IfcMaterialProperties which are invalid and superfluous. Although unrelated to georeferencing we published the fixed file to make it available for further uses.

Project C is a fantasy building with a location on a free spot of the KIT (Karlsruhe Institute of Technology) campus, which seems plausible in general, but a bit random and not fully intentional in the details, in particular regarding the rotation/true north which seems to differ from the surrounding buildings.

Project D, the pertinent Schependomlaan project,Footnote 9 originally contained an IFC2x3 style geolocation at N \(52^\circ \,9'\) E \(5^\circ 23'\) which is the city center of Amersfoort rounded to the minutes. This seems to be a common method for CAD software to populate the geolocation attributes during IFC export if only a city is given as the rough project location. Given that the architectural office is located in Amersfoort (according to IFC data), the default project location is likely set to the city of Amersfoort in the CAD software. The actual project location is only given as the city of Nijmegen and to find the respective address we employed Google street view to locate the iconic building along the street called Schependomlaan.

Project E is a sports hall in Amersfoort, Hambakendreef 2A, Netherlands, provided to demonstrate new georeferencing features in IFC4 and test and document a process to populate of the new attributes from Autodesk Revit.Footnote 10 The IFC was exported from Revit 2020 with standard RV MVD settings. In Revit, geolocation in WGS84 was initially determined from the given address and manual positioning on a large scale map, hence with a very rough location. The Revit IFC exporter then converted the WGS84 location to the Amersfoort CRS-EPSG 28992, resulting in a location of the WCS origin (eastings, northings = 149,692, 413,790) situated on a green space north of the building. However, the project base point is at the south most point of the building almost 100 m away from the determined location. For a corrected version, the WGS84 coordinates of the south-west point of the OpenStreetMap building polygon have been transformed to Amersfoort CRS with EPSG 4833 reversed. Further, issues with units from the original IFC Exporter version have been corrected manually.

Project F is a hand-crafted sample project, a fictitious building and was enriched with a georeference to a random building plot in Weimar.

Project G has an original georeference to N \(52^\circ ,31'\) E \(13^\circ ,24'\), which is a location in central Berlin on Museumsinsel, a touristic area. This seems to be a similar effect as observed in project D, just with a German default location, not a Dutch one.

4.2 Georeferencing Method

With this method, we generate IFC2x3 style georeferences.

First, we find the building polygon in OSM. Then, we identify two prominent outline points on a line that is horizontal in the engineering CS. We locate the respective points (hence geospatial coordinates) on the OSM outline polygon and can compute the angle.

In addition we ideally need an OSM node in the place of the Cartesian coordinate system origin, but this will rarely be the case, since the CS origin is usually on an axis intersection in the CAD plan. Axis, running in the interior of walls will naturally not lie on the building outline and thus constitute no node in common OSM data. We can locate the Cartesian CS origin by looking at the file in a CAD software or IFC viewer, there is usually some sort of axis cross that can be toggled visible. Using a building outline point P close by the origin, its Cartesian coordinates specify its relative location with respect to the origin. Hence, we can use these coordinates to calculate the angle and distance to the origin and apply these (taking the rotation from the first step into account in addition) to the geospatial coordinates of the OSM node corresponding to the chosen point P.

Finally, we can convert rotation and location to the required form for writing it to the IFC attributes.

Figure 3 shows the Schependomlaan (project D) building outline polygon in OSM. We chose two points on the northern edge for calculating the rotation: Pt 1 51.8419207, 5.8359716; Pt 2 51.8419708, 5.8361939.

Fig. 3
figure 3

OSM outline of Schependomlaan building with OSM nodes used for georeferencing: SW corner, two points on northern edge of the building outline

Full size image

The resulting bearing is 69.95911558532617 deg resulting in a normalized vector with abscissa 8.744136117400103E-7 and ordinate 2.3971081424637476E-6. The OSM node of the SW corner of the building outlin is located at 51.8417616, 5.8361467. From the IFC viewer we know its Cartesian coordinates 5050, 750 (mm) in the Engineering CS. From there, the origin (project base point) can be calculated to 51.84173969993845, 5.836081382150285 and in IFC representation, as a tuple of degrees, minuts, seconds, fraction of seconds we get (51, 50, 30, 262,919), (5, 50, 9, 892,975).

4.3 Discussion

The method applies similarly to IFC4 style references with the exception that coordinates have to be transformed to a suitabled mapped CRS. This has been done for Gymzaal Amersfoort, project E, which had only rough location when originally published. At the time of original publication, the export from Revit was not correct in terms of units. Thus, besides the exact location, units for the projected CRS were also fixed.

When using this method, it should be cared for validating the files and updating author information when changing IFC data sets. CAD vendors voice legitimate complaints about manipulated invalid files attributed to their certified software exports.

Also, one could discuss the proper place to put georeference: It is commonly assumed that georeferencing information should be contained with the IFC file. Many authors pose this as obvious or unavoidable. Certainly this is true when the geoinformation is provided as part of the original authoring. For after-the-fact enrichment this might be disputed, as the georeference might be specific to the target application, e.g. GIS, mapping or navigation application, and authority over the “correct” location is undetermined.

5 Coordinate Conversion

Given IFC data with more or less precise georeference information, the detailed building information can be leveraged in geospatial contexts. At some point, the geometry given in Cartesian coordinates with a georeferenced engineering CRS has to be transformed to geospatial coordinates. Depending on whether applications operating in the geospatial context can only handle geospatial CRS and coordinates or also georeferenced engineering CRS, this will happen in a preparatory data-transformation step, e.g. export or conversion into a geospatial format, or in the geospatial application itself upon import of the engineering data. In this section we discuss this conversion step and demonstrate it by example of creating OSM data from IFC.

5.1 Conversion Algorithms

With a georeference, the engineering coordinate system is anchored at a point on a well-defined model of the earth’s surface and oriented with respect to that geospatial model (datum). While this does provide reliable input for any conversion, it does not answer the more fundamental question of how to interpret the Cartesian coordinates with respect to a target CRS which may differ from the reference CRS. The most obvious interpretation from an engineer’s point of view is certainly a topocentric coordinate system with horizontal surfaces in the engineering CS corresponding to planes parallel to a reference ellipsoid’s tangent plane in the CS origin and the y-axis pointing north (Sect. 5.2). A second interpretation is with the horizontal surfaces corresponding to ellipsoidal surfaces.Footnote 11 And finally, we can also treat the coordinates as small numbers in a projected coordinate system, assuming that engineers plan their constructions on a map. Each of the three approaches yields a different conversion algorithm which will be discussed in the following sections. Further, we will demonstrate the three approaches by looking at two open source software implementations for IFC-to-OSM conversion as listed in Sect. 2.3.

5.2 Topocentric Cartesian CS

The topocentric coordinates can be converted to geodectic via geocentric coordinates as described in the EPSG method 9837.Footnote 12 Even though it is the most obvious interpretation, it is not yet implemented in any of the software.

5.3 Ellipsoidal Surfaces

Knowing the local distance d and bearing b from Cartesian point (x, y) to Cartesian origin \((x_0, y_0)\) the point can be converted to geodetic format by mapping d and b to the ellipsoidal surface. For this, d is converted into meters and b into degrees defined clockwise from y-axis. Then the searched latitude and longitude values \((\phi , \lambda )\) can be determined by calculating a new point at given distance and bearing to the known geodetic origin \((\phi _0, \lambda _0)\) as follows:

$$\begin{aligned} \phi &= \arcsin ( \sin \phi _0 * \cos \frac{d}{R} + \cos \phi _0 * \sin \frac{d}{R} * \cos b )\\ \lambda &= \lambda _0 + \text {atan2}( \sin b * \sin \frac{d}{R} * \cos \phi _0, \cos \frac{d}{R} - \sin \phi _0 * \sin \phi ) \\ \end{aligned}$$

with

$$\begin{aligned} b &= 90^\circ * - \text {atan2}( y-y_0, x-x_0 ) \\ d &= \sqrt{ (y-y_0)^2 + (x -x_0)^2 } \end{aligned}$$

and R being the earth’s radius. This approach is implemented in the JOSM Indoorhelper in the ParserGeoMath.cartesianToGeodetic method. Although this procedure can be applied regardless of how the CRS origin is specified, via IFC2x3 or IFC4 style georeferences, the Indoorhelper is currently only able to extract and process IFC2x3 style georeferences.

Fig. 4
figure 4

Calculating rotation from true north when converting via projected CRS

Full size image

5.4 Projected CRS

When interpreting the cartesian coordinate system as being based on a cartographic map, hence as a projected CRS, we can easily resort to the various existing conversion libraries such as proj4j which handle conversion between CRS’ and can even resolve them with their parameters from the EPSG code. However, the correct calculation of the rotation appears errorprone in implementations. It is challenging because it has to take into account the different angle’s reference axis and orientations as well as the true north directions as shown in Fig. 4.

This approach is implemented in the LevelOut platform in the ProjectedOriginCRS.cartesianToGeodetic method and in the GeodeticOriginCRS.cartesianToGeodetc method. These methods are applied depending on how the CRS origin is specified, via IFC2x3 or IFC4 style georeferences.

6 Verification with OSM Data

Table 2 Sample models with location in geo-context
Full size table

Finally, we verified the algorithms with those sample models which have an actual georeference either originally contained or received through enhancement as described in Sect. 4. Table 2 shows the resulting OSM data in geospatial context. Project C is left out because of its fantasy nature. The verification at this stage was carried out be visual inspection using JOSM and Indoor=.Footnote 13 A more thorough numerical validation measuring the deviation between the resulting OSM geometries and the original OSM polygons could yield a more substantive evaluation.

7 Conclusion

This use case study provides insight with practical examples in the population of georeferencing information in IFC as well as its interpretation and usage for conversion of geometry in Cartesian into WGS84 coordinates. Both the population and interpretation being based on freely available OSM data and open source implementation, this provides low-barrier guidance for spatially integrating BIM and GIS data as a base for further studies on applications using the integrated data.

There are various limitations and gaps in the current study. First of all there is no implementation of the topocentric coordinate system.

Second we did not do any numerical validation yet. The resulting fitting and deviation of the building outlines in IFC and OSM could be compared and evaluated.

Third, the level of detail and topology might vary between the OSM outline and the IFC outline such that it is not possible to identify sufficiently corresponding points. The variance might be to a degree that choice of corresponding points outweights the choice of conversion algorithm.

Finally, geodetic height deserves attention as well in the future.