The art of georeferencing and what you need to know

Jan 25, 2021

Georeferencing means to associate something with a location in physical space. The term is commonly used in the geographic information systems field to describe the process of associating a map or raster image of a map with geographical location. Georeferencing may be applied to any kind of object or structure that can be related to a geographical location, such as points of interest, roads, bridges, or buildings. Geographic locations are most commonly represented using a coordinate reference system, which in turn can be related to a geodetic reference system such as WGS-84.

Georeferencing in BIM and GIS

The correct geo-referencing of BIM 3D models plays a critical role in the BIM and GIS integration. While GIS can provide BIM a deeper context (e.g. for accounting the surrounding environment of a construction project), this can only work if the 3D model of the project can be properly located on a map of that environment. As we are mainly interested in open formats, by the term ”BIM” we mainly refer to the Industry Foundation Classes (IFC) format, which is the most renown open standard associated with the BIM paradigm. Properly geo-referencing an IFC file makes it possible to link the coordinates inside it with its real-world coordinates and thus to place the model of a single building or construction within the virtual environment.

Georeferencing an IFC

Proper georeferencing of an IFC file allows the link between the model of a single building or construction within its context and environment. There are several options to store georeferencing information in IFC, with varying level of detail. These options range from basic address information to the definition of an offset between the project coordinate system and the global origin of a coordinate reference system (CRS) and the corresponding rotation of the XY-Plane. By considering models coming from practice, it is possible to notice that the LoGeoRef20 option is the most commonly used within exported IFC models by BIM software. LoGeoRef30 is not an officially defined georeferencing method in the IFC standard but is sometimes adopted by software tools and practitioners. LoGeoRef50 is the best georeferencing options from a geodata/geomatics perspective, but is still quite uncommon in practice for building IFC models (likely more commonly used in infrastructure BIM models). It is usually complicated to understand if and how an IFC file is georeferenced, although some tools (e.g., the IfcGeoRefChecker at https:

//github.com/dd-bim/IfcGeoRef) are available to check this.

Levels of georeferencing (LoGeoRef)

Practical experiences show that BIM authoring tools export the georeferencing very differently to IFC files. While the result is syntactically correct the full spectrum of IFC possibilities is used, which may lead to a misunderstanding in another software importing the files. To have a common language, that can be used in BIM processes for describing Information Requirements (IR), BIM Execution Plan (BEP) or technical Exchange Requirement (ERs), this article proposes the so called LoGeoRef concept.

Concept Outline

The concept should be understood with the following “metric”: The higher the LoGeoRef of an IFC file is, the higher the quality of georeferencing is in the model. Higher levels do not automatically include information out of lower levels. Each level comprises its own IFC-schema attributes and is standing on its own. The metric is designed with decimal steps to allow intermediate steps e.g. for elevation, quality of attribute values or project-specific extensions.

LoGeoRef 10 (Postal Address, project management): The simplest way to describe a site or a building location is to add a postal address to the BIM project. Postal addresses are easily human readable and semi-structured for machines. For georeferencing purposes, it is only a rough approximation for setting the location of the site or the building. Nevertheless, it can be helpful for integrating GIS data like adding data of surrounding city models. The IFC schema provides an entity for storing address data in an IFC-file. The entity IfcPostalAddress contains multiple attributes including address lines, postal code, town, region and country. For a correct assignment to a spatial structure element, the IfcPostalAddress object has to be referenced by either IfcSite or IfcBuilding. Both entities include a certain attribute for address referencing.

LoGeoRef 20 (Geographic Coordinate, point on map):Geographic coordinates are another simple way for georeferencing IFC-files. For compliance with LoGeoRef 20, instances of IfcSite must contain values for their attributes RefLatitude and RefLongitude. As their names suggest an IFC model is able to store one single point coordinate with longitude and latitude directly in IfcSite. According to the IFC schema definition its values are geographic coordinates with respect to the World Geodetic System, i.e.WGS84 with EPSG:4326. Besides of that, it is also possible to store a value for the elevation in the corresponding attribute RefElevation. By definition, RefElevation should have a metric value related to a locally used datum relative to the sea level. However, there is no possibility to specify the datum´s name explicitly in the file. LoGeoRef 20 does not include possibilities to store any rotation parameters.

LoGeoRef 30 (3+1-Parameter for IfcSite Placement): LoGeoRef 30 describes the possibility to store the location of any IfcSpatialStructureElement directly in its LocalPlacement object. Subclasses that can be instantiated in an IFCfile are IfcSite, IfcBuilding, IfcBuildingStorey or IfcSpace. As an important constraint, LoGeoRef 30 applies only to those spatial structure elements that do not have a relative placement to another spatial structure element. Therefore, the attribute PlacementRelTo of the IfcLocalPlacement-object belonging to the IfcSpatialStructureElement should be empty (“$”). Usually this is the same spatial element, which is also the uppermost element in the spatial hierarchy. According to the IFC schema definition, this should always be an IfcSite-object. The attribute RelativePlacement is of type IfcAxis2Placement3D, so X-, Y- and Z coordinates for the location might be stored together with vector components for an angle specification for a rotation of the X-axis and the Z-axis. This makes it possible to store the placement for the translation to an arbitrary coordinate reference system (CRS) in the Location attribute and the rotation (true north) as vector of the specific axis respectively RefDirection attribute.

LoGeoRef 40 (3+1-Parameter using IfcProject with associated IfcGeometricRepresentationContext): LoGeoRef 40 provides two main attributes to store georeferencing attributes in an IFC-file. Both WorldCoordinateSystem and TrueNorth are part of the IfcGeometricRepresentationContext of an instantiated IfcProject. According to the IFC schema definition, every IFC-file contains an IfcProject and a referenced IfcGeometricRepresentationContext with the attribute ContextType given as “Model”. It is also possible to set up a coordinate system for the 3D-model context of the project via the attribute WorldCoordinateSystem. The other attributes follow the same rule as mentioned in previous LoGeoRef 30. A location stored in an instance of IfcCartesianPoint and optional directions for X- and Z-axis are stored in instances of IfcDirection. As a second main attribute, there is the TrueNorth attribute. This attribute is used in case the Y-axis of the given WorldCoordinateSystem does not point to the global northing. That means that this is another way to set a rotation for the XYplane. In consequence, the corresponding IfcDirection can only store two vector components.The TrueNorth attribute provides the option to set a distortion directly relative to the north direction. However, those options could be confusing and redundant when direction attributes are set at WorldCoordinateSystem and TrueNorth as it may happen when LoGeoRef 50 is fulfilled.

LoGeoRef 50 (3+1 Parameter and CRS Metadata) This level provides the highest quality regarding the georeferencing of an IFC-file. LoGeoRef50 can only be fulfilled by IFC-Files complying with IFC schema version 4. Previous IFC versions like the common IFC2x3 version can only store necessary attributes via user-defined IfcPropertySets. With IFC schema version 4 buildingSMART introduced some entities especially for georeferencing purposes. In particular, the entity IfcMapConversion stores the offset between project coordinate system and the global origin of a coordinate reference system with the attributes Eastings, Northings and OrthogonalHeight for global elevation. The rotation for the XYplane will be stored using the attributes XAxisAbscissa and XAxisOrdinate. Each attribute stores one vector component of the resulting angle (unlike the TrueNorth attribute with both vector components, see LoGeoRef 40). With the attribute scale a distortion of distances can be introduced in IfcMapConversion. The connection to the project is made by the attribute SourceCRS that is inherited from IfcCoordinateOperation. As a constraint of LoGeoRef 50 the SourceCRS must be of type IfcGeometricRepresentationContext. TargetCRS is consequently the Coordinate Reference System that should apply to the project. For describing these systems, IFC4 is able to store data regarding the CRS via an instance of IfcProjectedCRS. By schema definition, it is recommended to specify the CRS with an EPSG-code. However, it can also be specified via the other attributes of this entity.

LoGeoRef 60 (Set of common points in BIM and Geospatial domain): At present, there is no possibility to store any three-step transformation between the building project CRS (BIM), engineering CRS to a geodetic CRS in IFC. Concept of using control points for georeferencing (not implemented in IFC) The presumptive most reliable option to apply a transformation is the use of control points. Control points should have coordinate values in the local project/site/building system (BIM), the construction site system (engineering CRS) and in the geodetic CRS. It is up to the software manufacturers to provide functionality for transforming of BIM models into global geodetic systems. Possible data e.g. calculated transformation parameters could may be stored -without extending IFC schema- through generic property sets.

References

https://en.wikipedia.org/wiki/Georeferencing

https://3d.bk.tudelft.nl/pdfs/18_georeferencing.pdf

27. Clemen, C.; Hendrik, G. Level of Georeferencing (LoGeoRef) using IFC for BIM. J. Geod. 2019, 10, 15–20.

https://www.fig.net/resources/proceedings/fig_proceedings/fig2019/bim/Tim_Kaiser_Enrico_Romanschek.pdf

https://cpb-ap-se2.wpmucdn.com/blogs.unimelb.edu.au/dist/5/192/files/2020/09/wg-4-2-4-01-clemen-gorne-kaiser.pdf

Nandu Gagarin

Among with Marios Messios

Reliable Construction Management intern possessing effective time management and logical decision-making abilities.

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.