Automated Compliance Checks in AECO by Leveraging Semantic Technologies

This blog post demonstrates how knowledge graphs can automate building compliance checks by integrating land use plans with 3D building information models, using the Berlin TXL airport transformation as a real-world example.

People have been trying to automate building compliance checking for over 60 years. It might seem surprising, but even the very first researchers understood how much automation could help with problem solving in the Architecture, Engineering and Construction (AECO) domain.

Still, making this idea work completely wasn’t that simple. One big reason why automation hasn’t caught on faster in this area is that a lot of the data is still in analogue formats, like paper drawings and regulatory texts. In our previous blog post, we showed that it’s possible to automate the transformation of regulatory texts into knowledge graphs with the help of human experts and LLM-driven NLP routines.

Once transformed and loaded into Graphwise GraphDB, these regulatory texts become an organized knowledge graph that a compliance check service can reference. It’s easy to trace each regulation back to its source in the ground truth – the rule text that can be checked by an AECO expert. This information is then linked to 2D land parcel models and 3D building information models. When all that data is interconnected, the magic starts and we can automatically see how well a building project meets the rules.

Our use case

The former Berlin TXL airport undergoes a transformation that will allow adapted reuse of a heritage Terminal building as the center of the Urban Tech Republic, named Campus. The goal of this renovation is to attract innovation-based companies in digitalization, mobility, energy, materials, recycling, and water supply.

Tegel Projekt GmbH is a partner in the EU-funded ACCORD project as the building data provider, while the Agency for Geoinformation and Surveying Hamburg (LGV) contributes with land use data. Ordinance on the building use of land (BauNVO) serves as the main regulation, based on the Federal Building Code (BauGB). There are regulations developed for the specific area, supported by the bundle of the binding land use development plan (Bebauungsplan), its textual regulations, and the accompanying a specific justification (Begründung) document.

A detective with the Source Data

In this scenario, we have 2D land plans for the intended use and a 3D building information model (BIM). We want to check if the 3D BIM follows the rules for allowed land uses. If any discrepancies or violations are detected, it should be redesigned to comply with the current national regulations. Years of urban planning practice have made it obvious that doing these checks by “pen and paper” takes a lot of time, is error-prone and inconsistent, and needs to be automated.

For our purposes, we had 2D land plans in two formats. One was the national standard XPlan, which had all the details about allowed land use. The other was the EU Infrastructure for Spatial Information in Europe (INSPIRE). It had only partial correspondence to XPlan because of the unified (and thus simplified in our case) nature of INSPIRE.

Everything was in German – the texts of the regulations, land use plans, and BIM. Also, as XPlan is the German national standard of land use presentation, it’s a profile of GML 3 and doesn’t have RDF rendition. In this case, we worked with the source data as illustrated in this XPlan sample.

However, even though INSPIRE provides the data in RDF, some information got lost when converting from XPlan to INSPIRE. So, we worked with the source data in XPlan and used xSPARQL for the conversion. You can see the converted XPlan data in this sample.

Integrating the BIM data into the knowledge graph was even trickier. We had problems with the source data format as well as its geometry presentation.

Geometry representation

The initial model was based on Industry Foundation Classes (IFC) – a standard enabling interoperability in AECO. It used a projected local coordinate system (Berlin Soldner, EPSG:3068), which differed from the official German spatial reference system ETRS89_UTM33 (EPSG:25833) used in the development plan. By converting the model to CityGML and applying a Python script, which performed offsetting according to IfcMapConversion attributes, the coordinates were re-projected to align with the ETRS89_UTM33 zone. This ensured spatial consistency between the model and the development plan.

We also converted all geometries for land and for BIM from GML to WKT and GeoJSON. WKT literals can be imported to GraphDB and, in order to make queries over geodata, we need geometries serialized in WKT. As GeoJSON is used in visualization tools, having it materialized instead of calculating it on the fly ensured fast visualization of big BIM files. Topological relations between geometries were also materialized as a result of data processing by a Python script that used the GDAL library.

IFC conversion

The IFC format widely used in AECO has one complete translation into OWL – ifcOWL. There is also IFCtoLBD for generating W3C LBD CG compliant RDF files and Simple BIM aiming to reduce the size of IfcOWL generated files. While trying the existing approaches, we ended up with a tenfold increase of the resulting RDF file size. The ifcOWL transformation introduced a lot of intermediate nodes to make the conversion OWL-conformant and self-describing. However, writing a “production” SPARQL over it leads to cumbersome workflow, which makes it difficult to maintain and change queries. This motivated us to look for any other less resource intensive options.

And we found a solution!

IFC files can be converted with FME into CityGML format and you can take a look at the resulting GML file in this IFC-CityGML sample.

We used another custom xSPARQL script to do the rest of the job. It converted CityGML into CityRDF (a novel RDF rendition of CityGML in OWL/RDF, proposed in the ACCORD project). It’s up to the level of polygons, while preserving all the necessary IFC data. We carefully, and iteratively, chose what data to include to create an RDF file that could be efficiently used for compliance checks. You can see the result in this BIM data sample).

The overall workflow is depicted in the diagram below:

As a result, for each land use development plan we have two named knowledge graphs –  /landuse and /ifc – filled with data and loaded into GraphDB.

The topological relationships between land parcels and geometries available in BIM are stored separately in /topological knowledge graph. They employ the GeoSPARQL ontology vocabulary and are used for geospatial queries. There is an additional graph /2dfootprint for the 2d footprint of the BIM.

Now let’s show how compliance checks can be done the SPARQL way.

Querying AECO knowledge graphs

SPARQL is a universal query language, enabling interoperability at both semantic and technological layers. In a single SPARQL query we simultaneously operate on land parcel geometries as well as elements of BIM models (floor geometries, heights of rooms, heights of building parts, doing comparisons, finding intersections and coincident elements from BIM and from land use plans). As already mentioned, both models were sourced from different data formats and geometry representations. 

We implemented some compliance checks, including the following :

1. Is the building design contained within the development plan?
2. Are all parts of the building contained within permissible lot coverage?
3. Does residential use of all building rooms not exceed 5%?
4. Is office use of all building rooms not less than 60%?
5. Does the building floor space index (FSI) exceed the planned floor space index in the development plan?
6. Is the building higher than permitted by the development plan?
7. Is the building within a heritage protection area?
8. Is the building within an area with additional noise regulations?
9. Does the building cross a building boundary?
10. Is the majority (at least 90%) of the building 2d footprint within the allowed building sub area?

The topological relations between land parcels and the (projections) of BIM to the land were  materialized to reflect GeoSPARQL terminology. In our scenario, some regulation rule could not be checked as the BIM model did not include all the necessary data. For example, several rules in XPlan defined the allowed level of noise during the day and the night at particular places of the building. However, in the IFC, there was no data (no available noise fences) to check. Similarly, requirements of roof planting, allowed roof biodiversity, trees shielding the pathways, and some other details were present in XPlan but were missing in the provided IFC model.

Still, it was possible to check the majority of the rules. Most importantly, we were able to successfully implement the geometry checks, such as allowed height, building lines and boundaries, and usages of the land parcel.

Outcomes

We have demonstrated that knowledge graphs can enable automated building compliance checks by employing land use data and building information models.

Currently, writing SPARQL queries for these compliance checks is not automated and requires close collaboration with AECO engineers to ensure regulations are accurately interpreted and encoded into SPARQL. However, recent advancements in natural language querying over knowledge graphs, especially Graphwise’s Talk-to-Your-Graph initiative show promising ways to automate this rule creation process.

By employing more comprehensive IFC models and digitizing whole building or land use codes (the whole XPlan in our case), we can create a more comprehensive set of automated compliance checks that cover all regulations for a country’s building standards.

By creating a digital link between building codes and IFC/CityGML building models, we can automatically verify if building designs meet legal requirements and regulations. These automated checks can cover multiple areas including structural integrity, fire safety, energy efficiency, and accessibility. This helps architects, engineers, and builders make better decisions throughout the design, construction, and maintenance phases, while ensuring buildings meet all compliance standards and promoting semantic technology best practices in AECO.

Stay tuned!

Meanwhile, if you download GraphDB and check its documentation, you can see some examples of how this enriched data could be retrieved with GeoSPARQL.