Unlocking the Potential of BIM Data

BIM (Building Information Modeling) plays an important role in modern construction and architectural project. There are a lot of potential use-cases for BIM data if we can extract it into a data analysis tool like Power BI. At the same time there are also a number of challenges when trying to extract large amounts of data out of Revit at once.

This article provides an overview of tools, techniques, and workflows for making the most out of BIM data for everyone, especially those who are not experts in Autodesk Revit.

‍

The Extract, Transform, and Load Process

To make the most out of your data, we need to first get it out of the design documents (e.g., Revit or IFC) and into a form that is appropriate for performing analytics.

This is part of a process known as ETL (Extract, Transform, and Load). ETL is the process of combining data from one or more sources into a central data container. This data container could be a spreadsheet, a database, or a data-lake.

Once in a data-container specialized data analysis and visualization tools like Power BI and Tableau can be used.

‍

Exporting BIM Data to Excel

One of the most widely known methods for extracting data out of Revit is via Revit schedules. Revit schedules support exporting to spreadsheet compatible formats as either CSV (Comma Separated Values) or Excel files.

One challenge with a Revit schedule is that it is generally a manual process which can be very time consuming to configure and perform. Ultimately we want all of the data extracted and then loaded into a database so that we can filter it as needed using standard tools like SQL.

With a bit of programming experience, it is possible to automate the export process to CSV via the Revit API, PyRevit scripts, or Dynamo, but configuring the schedules remains manual.

‍

Limitations of Spreadsheets

Bringing BIM data into Excel first can be a quick way to get started bringing BIM data into a database, however it doesn’t scale very well for larger data intensive projects, let alone multiple projects simultaneously.

Excel is a spreadsheet software designed for small datasets and ad-hoc analysis. It lacks much of the useful functionality of a modern relational database.

Poor performance for large data sets

Limited to 1 million rows of data

Lack of support for collaborative workflows

Lack of standardized tools (e.g., SQL) for querying data

Lack of validation

Hard to represent complex data relationships

‍

Revit DB Link

One way to bring BIM data directly into a database is via a plug-in from Autodesk called Revit DB Link (https://help.autodesk.com/view/RVT/2023/ENU/?guid=GUID-639C5DB8-3AB7-4803-9EFE-72CA4F714F69).

Revit DB Link’s advertised role is to project data into the database, make changes to the data, and import it back into the project. Importing data back into a project is of limited value, as it may violate the design constraints that are either implicit or explicit in the Revit project.

DB Link does offer a tantalizing glimpse of an ETL workflow for bringing data into a database.

Again, the problem faced by most users is that it does not perform well at scale.

One of the reasons is that the default schema (aka the structure) of the data as it is imported into the database is one table per family type, and one column per parameter, with very limited overlap.

Initially this makes sense, but there are a few problems:

Lots of repeated data

Doesn’t capture some of the more complex relationships.

Generates too many tables (many of which are unfortunately empty).

Exporting just the sample Revit house generated 240 tables.

Bringing this data into Power BI brought it to its knees. The schema is too complex to visualize.

A screenshot of a computerDescription automatically generated

Another Approach to BIM Database Schemas: Using the Revit API as an ORM

So, if the Revit DB Link approach of producing one table per family type is not tractable, what is the alternative?

Another approach is to create a database schema based on the Revit API. The Revit API represents the intrinsic BIM data as a set of objects with relationships. A technique in software engineering called object relational mapping (ORM) provides a way of automating the mapping between relationships within an object oriented model to a relational database model.

https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping

The Revit API is well-documented (https://www.revitapidocs.com/) and mapping the relevant portions of it into an object model that is appropriate for a database is a relatively straightforward software-engineering task.

This was the approach used by the VIM Revit exporter. The VIM format open-source repository provides a schema of the object model used here:

https://github.com/vimaec/vim-format/blob/develop/src/cs/vim/Vim.Format/ObjectModel/ObjectModel.cs

For anyone familiar with the Revit API, it becomes quickly apparent that this object model is effectively a cherry-picked subset of the Revit API. It makes sense to not export everything, given that the Revit API does carry additional data just for the purpose of visualizing the model, and operating the software.

In the end it turns out to also be an efficient representation of the data as a relational database. The VIM team leveraged this representation to create Power BI reports, and the schema is much easier to work with than data extracted out of Revit API.

Final Words

As with any engineering effort, there is no perfect solution. There are always trade-offs to be made depending on your specific needs. The VIM relational schema for BIM data for example is efficient (in terms of space, and time to execute a query), but creating queries and exploring the data is more complex because the desired data is spread across multiple tables.

If you are aware of other approaches or techniques for bringing BIM data into a database, please share it with us!