BIM to GIS (Intermediate) | IFC LOD 300 to LOD 4 CityGML

Liz Sanderson
Liz Sanderson
  • Updated

Introduction

Both IFC and CityGML have a hierarchical data structure. However, IFC’s structure is more complex and includes intermediate features that are not required in CityGML. For example, in IFC, Doors are children of Openings, which in turn are children of Walls, whereas in CityGML, Doors are children of Walls.

As well, the features are grouped somewhat differently. For example, parts of windows and stairs are contained in the IFC Member feature and must be added to their parent feature when converting to CityGML.

This example shows how to convert a highly detailed IFC model into a CityGML model with a Level of Detail (LOD) of 4. This workspace is comprehensive enough to handle most Architectural IFC datasets.

This article uses the IFC STEP/XML reader or writer, which was deprecated in FME 2025.0. To continue with this article, please use FME 2024.2 or older.

Downloads

Step-by-step Instructions

Due to the sheer complexity of this workspace, this tutorial is a high-level overview. For parameter specifics, please open the workspace. Key parameters are mentioned.

Source Data

This workspace uses the DC Riverside Building LOD 300 IFC file, before beginning please download the data, which is from the Vectorworks website.

sourcedata.png

DC_Riverside_Bldg_LOD_300.ifc viewed in Solibri Model Viewer

Part 1: Create parent/child lookup

IFC features have links to their parent features, but to remove unnecessary intermediate features (like Openings), we also need links to the grandparent features. To do this, we use two separate Industry Foundation Class STEP (IFC) readers. This first reader reads all IFC features, populates a lookup table of feature and parent IDs as variables, and a lookup table of parent types. Because this first reader does not use the IFC geometry, it runs quickly. FME runs its readers sequentially, so this reader will finish, and the lookup tables will be completely populated before the second reader starts.

parentlookup.png

Create a parent/child lookup table

Part 2: Create a Building

The second IFC reader is used for the data conversion. The Building is a simple conversion to remove any geometry using the GeometryRemover transformer and then an AttributeRenamer transformer to set the ifc_unique_id to the gml_id.

simplebuildingworkflow.png

A simple conversion to remove geometry from the building

Part 3: Convert Complex IFC Solid Geometry to MultiSurface

All conversions will need to convert the geometry from a complex IFC solid to a MultiSurface that can be written to CityGML, so a custom transformer called ConvertGeometry is created to quickly replicate this process.

convertgeometrytransformer.png

Within the ConvertGeometry custom transformer, the IFC solid geometry is separated from the property sets by a GeometryPartExtractor transformer, and then converted to surfaces by a GeometryCoercer transformer. Then, to flatten the multi-level geometry, it was disaggregated using the Deaggregator transformer with the Mode set to Flatten All. Then the geometry is re-aggregated into MultiSurfaces using the Aggregator transformer, with the Mode set to Geometry - Assemble One Level, and the GeometryRefiner transformer.

convertgeometry.png

ConvertGeometry custom transformer workflow

Part 4: Get Grandparent ID

Almost all features have their parent link set to the IFC Building Story, instead of the Building, so we need to move up one link to create the CityGML parent link to the Building, using the lookup tables stored in the variables. Since this will be repeated throughout the workspace, another custom transformer, GetGrandParentID, is created.

getgranparenttransformer.png

A BinaryEncoder transformer is used with a User Parameter created for Attribute to Encode. Then a VariableRetriever transformer is added to set the _gparent_id. Finally, the _gparent_id is decoded, and another User Parameter is created for Destination Attribute using the BinaryDecoder transformer.

getgrandparentid.png

GetGrandParentID custom transformer workflow

Part 5: Set CityGML LOD Name and Feature Role

Before writing out to CityGML, a couple of attributes always need to be set following a strict naming convention. A CityGMLGeometrySetter custom transformer has been created to prevent data entry errors and is available on the FME Hub. This transformer sets the CityGML LOD Name and the Feature Role.

Part 6: Simple conversions

Simple conversions require minimal filtering, if any at all, before writing out to CityGML. The main workflow goes as follows:

  1. Read in IFC data
  2. ConvertGeometry
  3. Set the gml_id
  4. GetGrandparentID
  5. CityGMLGeometrySetter
  6. Write out to CityGML

ifcspaceworkflow.png

Example simple conversion, converting IfcSpace to a CityGML Room

Part 7: Complex conversions

CityGML BuildingInstallation and WallSurface features consist of multiple IFC feature types, and some IFC features may be part of both. IFC Members, StairFlights, Slabs, and Railings are combined into Stairs, which are then written as BuildingInstallations, along with Columns and Beams. Other Members are combined into CurtainWalls, which are written out to WallsSurfaces, as are IFC features Wall and WallStandardCase.

These separations and combinations can require several lookups of parent type and grandparent IDs from the variables created by the first IFC reader.

Part 8: Results

outputdata.png

Output CityGML file viewed in FZK Viewer

Data Attribution

Riverside Building demo project data produced by Nemetschek Vectorworks.

Was this article helpful?

We're sorry to hear that.

Please tell us why.

As of January 14th, 2026, comments on knowledge base articles have been closed. To make sure questions don’t get missed and to enable more community support, we’ve moved discussions to the FME Community. If you have a question or a comment about this article, please create a new post or create a support ticket.