IFC Coordinate Reference Systems and Revit

Dion Moult

2019-05-21

Revit has three reference points for coordinates: the internal origin, a survey point, and a project base point. The project base point may have an angle to true north set. When you export to IFC, an IfcProject and IfcSite is created. Both elements have coordinates and data. However, are these coordinates correct? Are they complete? And can we use them reliably in other software? Let's investigate.

Coordinate systems defined by IfcProject

Let's talk about what we want the results to be. According to the IFC specification, IfcProject provides the following information:

This information is provided using the RepresentationContexts relationship of the IfcProject. This relationship will contain one or more IfcGeometricRepresentationContext elements. Each will typically have a CoordinateSpaceDimension of 3, to show a 3D model, and the Precision attribute shows the model precision.

The actual project coordinate system is defined by the HasCoordinateOperation relationship. This holds an IfcMapConversion element, which in turn references an IfcProjectedCRS. Let's go through the attributes of IfcProjectedCRS first, as knowing the Coordinate Reference System (CRS) of the project is the most critical aspect of geeoreferencing:

Now that the projected CRS is defined, we need to define whether or not there are any map conversions between our model's local coordinate system and the map coordinate system. Typically for horizontal construction projects, such as roads, rail, and other linear infrastructure, there would be no map conversion, and the local coordiante system will directly use Eastings and Northings of the map coordinate system. However, for vertical construction projects, such as buildings, there will almost always be a map conversion converting from small, local, XYZ coordinates, to map eastings, northings, and height coordinates. Here are the attributes of the IfcMapConversion:

This IfcMapConversion and IfcProjectedCRS element of the IfcProject's IfcGeometricRepresentationContext holds all of the georeferencing information that we require. These attributes contains all of the parameters required to perform a "Helmert transformation", which is a fancy way of saying how to offset, rotate, and scale local project coordinates to a globally positioned coordinate system. For your surveyor to provide these transformation parameters properly, they will need multiple surveyed points (a minimum of two), ideally taken at extremes across the site, in both your local coordinates, as well as their equivalents in the target CRS. They will also need to know your desired building orientation (i.e. project north) to calculate the X axis abcissa and ordinate, and a nominated false origin to set the Eastings and Northings. The more points that are surveyed, the more accurate this IfcMapConversion will become.

With all of the information defined above, to convert from local coordinates (X, Y, Z), to map grid coordinates (X', Y', Z'), you can use these relationships:

How to convert from project to a target CRS coordinates

Credits go to BuildingSmart Australasia who has done great work in clarifying these concepts. Note that I have clarified the argument order of the atan2 function is y, x, which is more common in programming languages.

After all of this information is recorded, it's interesting to note that the IfcGeometricRepresentationContext additionally has a TrueNorth attribute. Assuming the IfcMapConversion is already provided, there is actually no need for a TrueNorth attribute, and so if it is provided, it is merely duplicate data and there for convenience. IFC readers should not parse it and should not apply the same rotation twice. The IfcMapConversion takes priority over the TrueNorth attribute.

The WorldCoordinateSystem attribute

The IfcGeometricRepresentationContext of the IfcProject also has a WorldCoordinateSystem attribute. Usually, this will be set to (0, 0, 0), and represents the origin of the virtual world. In other words, any element in a project usually inherit the local relative placement of its parent, all the way up to IfcSite, but somewhere, it needs to end in an absolute coordinate. This WorldCoordinateSystem is the final absolute coordinate that is not relative to anything else. It can therefore be used to offset everything in your project, should you want to. The IfcMapConversion we just described, will then be used to convert our virtual world into the real world.

Coordinate system inheritance

The IfcSite is spatially contained in the IfcProject. However, the spatial containment is not the determining factor for how coordinates are inherited. Instead, the IfcSite has an ObjectPlacement and a Representation attribute. These are the important attributes to pay attention to.

The ObjectPlacement attribute positions the IfcSite element relative to other objects. We will discuss about different placements below, but suffice to say that it merely deals with relative offsets of coordinates.

The Representation attribute, however, contains an IfcRepresentationContext chosen from the list of contexts defined at the IfcProject level. It is this particular selection of the IfcRepresentationContext that allows the IfcSite to inherit a particular WorldCoordinateSystem and MapConversion attribute defined at the IfcProject level.

I would like to emphasize that the coordinate transformation is not due to spatial containment or hierarchy, but instead due to the selection of IfcRepresentationContext.

In theory, any IFC product that has a representation can select its own context. This means that an IfcWall can have one map conversion, and have an ObjectPlacement to another IFC element which has a different map conversion. Although technically syntactically correct, it's considered invalid as it is bad practice and seasoned GIS professionals will tell you to never mix different CRSes on one map unless you want to be more artistic than useful.

Coordinate systems defined by IfcSite

In addition to ordinary coordinates, the IfcSite provides RefLatitude, RefLongitutde, and RefElevation attributes. As the prefix "Ref" suggests, this is a latitude and longitutde provided only for reference. It is not sufficient for proper geolocation and if there is a discrepancy between the IfcMapConversion and the data provided in IfcSite, the IfcMapConversion takes priority.

Note that these RefLatitude and RefLongitude values are recorded in integers that are separated by a full stop to represent degrees, minutes, seconds, and an optional millionths of a second. West and south locations are negative, and east and north locations are positive.

In a real project, a project may contain multiple IfcSite objects. Each IfcSite has a Representation, which may include terrain, for example. For most projects, there is a site boundary, such as a cadastral boundary which denotes the legal plot of land. The ObjectPlacement of the IfcSite is therefore likely to be a corner of the site boundary which is a point that has been surveyed.

Coordinate systems defined by IfcBuilding

The IfcBuilding contains a Representation of the building. It also contains an IfcObjectPlacement, which is relative to the IfcSite. This would place your building on your site model. The rotation of this placement also sets out the project north of the building. If your building has multiple wings, it may also define the individual project norths of each wing.

The IfcBuilding additionally contains two attributes:

Just like the reference point values in IfcSite, these are also duplications of data. It is not explicitly mentioned, but I believe that should there be a discrepancy, the derived coordinate from the IfcMapConversion takes priority.

The ElevationOfTerrain, apart from being a reference value, also provides a datum to measure the EavesHeight and the Height (total height) of the building which is recorded in the Qto_BuildingBaseQuantities.

Absolute coordinates

If your object has an IfcObjectPlacement, it usually uses an IfcLocalPlacement which has a PlacementRelTo, thus inheriting the parent's placement. If you omit the PlacementRelTo, it does not inherit any more parent coordinates, and ends up being an absolute coordinate. An absolute coordinate is defined as only relative to the WorldCoordinateSystem of the IfcProject.

A common example for this is the IfcSite element which is the immediate child of the IfcProject. Because its only parent coordinate is the WorldCoordinateSystem, it is known as an absolute placement.

You can also omit the IfcObjectPlacement altogether, and it will therefore also be treated as an absolute placement which is equal to the WorldCoordinateSystem of the IfcProject.

Omission of the IfcObjectPlacement is a quick and easy way to say that your IfcBuildingStorey, IfcBuilding, and IfcSite, are all at the WorldCoordinateSystem. This behaviour has been noted in some software, such as Revit in some circumstances.

Keep in mind that this behaviour is technically possible but it is not endorsed by buildingSMART. For more information, see this ISG implementation agreement CV-2x3-143 agreement on having the containment tree and the relative placement tree identical for spatial elements. It is only mentioned out of completeness.

Coordinate systems and IfcGrid

Grids are by convention (i.e. described not enforced by the IFC specification) placed relative to the local placement of its container. Grids can be contained by IfcSite, IfcBuilding, or IfcBuildingStorey. As an alternative to a relative and absolute placements, coordinates can also be specified constrained to a grid system. This is as simple as using IfcGridPlacement for the IfcObjectPlacement.

Using IfcGridPlacement allows you to specify an object's placement using the intersection of two grid lines, or IfcVirtualGridIntersection, and a direction. The details will not be described here, but using grids does not change the fundamental concept of site coordinates. Any object placed this way will still resolve to a local (X, Y, Z) which can be translated using the IfcMapConversion.

It is therefore possible to have an IfcGrid spatially contained by an IfcSite. The IfcBuilding could then have a placement aligning with the grid. This makes intuitive sense to lay a building out relative to a grid placed on the site, but it breaks the ISG agreement where containment tree and relative placement tree should be identical.

Spatial Composition and coordinates

For the objects that we've described so far, they usually use the Spatial Composition concept to relate to one another. Keep in mind that spatial decomposition and inheritance of coordinates are two separate concepts. Just because something is spatially contained in a parent container does not mean that it inherits its coordinates.

However, that being said, a convention is endorsed by the specification's documentation of IfcLocalPlacement to place objects relative to the same container that it is spatially contained in. I've linked the page for you to read the details of the relationships that are endorsed.

Coordinate systems created by Revit

Now that we know what should be defined and how they should be defined in an ideal world, let's take a Revit project as an example. We will be exporting using the open source Revit exporter as an IFC4 file.

Revit provides an IfcProject as expected, and this has one IfcGeometricRepresentationContext. Unfortunately, our luck ends here, as no IfcMapConversion is provided. Therefore, all that great stuff we talked about where we could record a CRS, its datums and projections, and so on, are not available.

Let's see what information we do have in the IfcProject's IfcGeometricRepresentationContext:

An IfcSite is also provided with the following information.

The final information we can extract is the ObjectPlacement attribute of the IfcSite element. This has a location and a direction. The direction is identical to the TrueNorth value described above, but has a Z dimension too. The Z dimension may be set to the Elev field of the Revit Project Base Point, if the "Include IFCSITE elevation in the site local placement origin" option is checked in the "Advanced" tab of the IFC export settings. If the option is not checked, it is set to 0.

Credits to Niel Simmonds for clarifying the behaviour of elevation data.

The Location of the IfcSite, however, is a bit of a tricky one. It is a 3D coordinate, with the Z ordinate always set to 0. The X and Y ordinates have a relationship to the project base point (PBP) as shown below. Revit further complicates things by having a project base point that can be represented by eastings and northings that are relative to either the survey point, or the project's invisible internal origin point. These are denoted with the subscript Survey and Origin respectively.

How to derive Revit's IfcSite coordinates

The IfcBuilding is always set to a relative placement of (0, 0, 0), and therefore fully inherits the location of the IfcSite. However, I have seen elevation data at the IfcBuildingStorey level, set in its ObjectPlacement's Location Z ordinate (X and Y are hardcoded at 0, 0). In particular, this Z value will not be the value you set in your Revit level schedule. Instead, it will be your Revit level value plus the Elev value of your Project Base Point. As a result, your building will always have "absolute" height values in its IFC export, even though it may not be inherited or stored at the location recommended by the IFC spec. I should note that the Elev value set on your Revit Survey Point has no impact whatsoever on the IFC export.

It should be noted that Revit does not know what a building or site is and so it is not possible to have multiple buildings, building portions, sites, or sub-sites. All files automatically generate and contain all of their contents inside a single site and single building.

Knowing this information is extremely important. Because Revit does not specify a CRS conversion, many people put their local CRS eastings and northings coordinates into the project base point and the survey point. As most of these values are very large in magnitude, the IfcSite local placement will too be extremely far off in space.

This far site placement is inherited by every single object spatially contained by the site. Any program which then parses the IFC to extract the geometry will have to deal with this, and the inability to deal with such large transformation magnitudes is a well known problem in the 3D industry. As a result, geometry gets unnecessarily "broken" and imports are unreliable. You can experience this yourself by importing an IFC into Blender which has CRS coordinates, or even attempting to import an IFC back into Revit: it won't be able to handle its own creation.

As a workaround, you can simply modify the IfcLocalPlacement of the IfcSite in a text editor before importing the IFC. After the import, you can then specify using native GIS features of your application how the origin point translates to a target CRS. Knowing the relationship of the IfcSite coordinates above will help you specify the origin correctly. I tend to simply reset the value such that the origin point corresponds with the project base point. In simple scenarios this is (0, 0, 0), but sometimes it may have a further offset which you can calculate using the formula above. An alternative, simpler way is by finding the difference in coordinates between the IfcSite and Revit's project base point, and making that the new IfcSite local placement Location.

This article should clarify all coordinate related concepts in BIM and Revit, and hopefully you can now use IFCs a bit more reliably across other software other than Revit.

Comments

If you have any comments, please send them to dion@thinkmoult.com.