Clash API with Power BI

Note: This is a (slightly) advanced topic. Please post any follow-up questions/comments at the bottom.

Clash detection management with iTwins and Power BI.

To start out — let’s define a clash. A clash is when two elements in a 3d model share the same space. This causes bad stuff to happen. Really bad stuff. Luckily, clash detection saves the day!

Using clash detection is great to detect and resolve issues before these become a costly affair during construction. Keeping track of the number of clashes at any time is important. Nobody wants to see the number of clashes suddenly spiraling out of control. What we want to see is a steady decline of such interferences over time, a great indicator that the team is actively looking at clashes and working to resolve them.

Regardless of up or down, it’s time to track those clashes and take control! Since everyone loves graphs and charts… Power BI dashboards are perfect for this.

Image 1 — Clash Detection Dashboard

Getting Started

To make this work, we need to actually create some clash definitions first. This can be done using iTwin clash API-powered applications.

In this case, I am using one such application…called iTwin Design Review. For anyone not familiar with the product, Design Review is a complete model visualization and checking suite.

Clash detection tests are easy to create and can be based on model files or element categories. Various options such as tolerances and suppression rules can be defined quickly and adjusted as needed. Tests can be performed against different iModels and their versions. Results are visualized in a 3D environment where mark-ups can be created and assigned to team members. This allows for very efficient clash detection and resolution workflows.

In this article, we are focusing on viewing results using Power BI.

API Heaven

There are two main steps in the clash workflow.

1. GET clash runs.
2. GET result details for the runs.

Clash Detection

We will be using these steps to create the Power BI dashboard. A basic dashboard would involve:

1 — Viewing the list of clash definitions, the element categories covered, and the results.

2 — Details of the results, which include the list of actual clashing elements, the categories/models they belong to, and what type of clash (eg. collision or clearance).

Let’s start with the first step/API call.

1. GET clash detection runs

GET https://api.bentley.com/clashdetection/runs?projectId

This will retrieve all clash detection runs performed against a project model. All it requires is the project ID.

It will provide the name of the clash test, date, count of clashes, creator's name, its status and most importantly the result ID. The result ID is required for the next API request.

2. GET clash result details

GET https://api.bentley.com/clashdetection/results/{id}

Here we can expect amongst others the model’s name, ID and name of clashing elements, their category, and coordinates.

Digging Deeper

To test out the above API calls, the try-it-out feature is available in the API documentation. It lets a user test out the functionality within the browser. We can use the responses from these calls to hook up our clash information to Power BI (using web connections).

For readers not familiar with API connections to Power BI, please refer to the 2nd part of this article where I will describe the entire process step by step.

1. GET clash detection runs

This request will provide a complete list of all clash runs ever performed on a project. For an ongoing project, this could be several hundred rows long.

Image 2 — Get clash detection runs

After a bit of a clean-up, where I removed some unnecessary columns, split names with dates, and converted text to dates.

Image 3 — cleaned up a bit

This is all we need to do here, and the data is ready to be loaded into the Power BI visualizer.

Dashboard creation

In this section, we look at the results and check what we can do with them in Power BI.

Once the data is loaded, it is time to take your Power BI skills to the test. I like to experiment with different visualizations, and each of them has a different value in showing the right information. Having at least one list and offering the option to export data makes it more user-friendly.

Image 4 — Clash set overview

The above dashboard gives an excellent overview of what is going on. It not only lists all clash detection runs but also offers the option to select individual sets using various filters.

Image 5 — Walls vs Ducts

Looking at a specific set we can see that not a lot has been done to resolve clashes and the amount remains pegged at a high level. Maybe it’s time to send the team a (very) friendly reminder. 😊

A time slider can help to narrow down the results on complex and long-running projects.

Tracking and monitoring progress is great, but we also need to investigate the details of the most recent individual clashes.

The second API call will provide us with exactly that information.

2. GET clash result details

For this request, we require the result ID included in the previous get clash detection run request. Simply processing all result IDs (for all the runs) would produce an incredible amount of data. For my simple test project, I only have 4 clash sets with a total of 23 runs. This adds up to a total of more than 8000 processed rows. Imagine this on a large-scale project with dozens of clash test sets. I made this mistake once!

Image 6 — will they ever stop?

To reduce the amount of data I only want the latest runs. I can filter the results by date and time to get just the latest result IDs. I can then generate an API request using these IDs.

https://api.bentley.com/clashdetection/results/{id}

BAM! And now I can see my results.

Image 7 — Clearance check

This shows a list of elements with clearance clash issues.

This would not replace your clash review process but rather complement it. A great clash detection tool such as Design Review still plays a very important part.

I hope this gave a brief overview of what is possible with Bentley’s clash detection API and provided some inspiration on how to enhance and make a tedious process more fun.

What’s next?

There’s always more data to be discovered :)

For example, each clash has its coordinates. Displaying these in a heatmap, and identifying hotspots of clashes on a map would be great to experiment with. Furthermore, integrating the dashboard into an iTwin app and having direct access to the model like the sample here:

iTwin.js

How are you keeping track of clashes and working towards a more efficient workflow? Let me know in the comments.