In the past few days, The 3D Web Coder documented the first steps of research for a re-implementation of the Revit SDK FireRating sample in the cloud, and Daren Thomas pointed out his new project driving Revit and the Revit Python Shell through a REST API:
Summer has arrived in Switzerland! This entire week is expected to be hot and sunny with temperatures up to 36 degrees Celsius. The Rhine is full of swimmers in the middle of the city of Basle, competing for space with the barges:
The venerable old FireRating Revit SDK sample has proved extremely useful over the years.
I described it in detail in the discussion on exporting parameter data to Excel, and re-importing.
It is a VB.NET add-in, implementing the following three steps in three separate external commands:
These three also found their way into the ADN Xtra labs, where they are implemented twice over, in C# as well as VB.NET, in three corresponding external commands:
The entire FireRating data management consists of storing the following four columns of data in the external spreadsheet, with one row of data populated for each door instance:
The level and tag data are actually never used by the application.
Being rather old and unwary, the sample uses the element id to identify the individual door instances.
That is strongly discouraged, since the element id can be modified by worksharing operations.
When associating external data with an individual Revit element, you should always use its unique id instead.
Furthermore, the element id can only be used to identify elements within one single Revit project, since it is currently more or less just a simple consecutive integer number assigned to reach element in the order of its creation.
The unique id is globally unique though, across all Revit project in the universe – always assuming that you have not made copies of a project, in which case the unique ids of the existing elements will obviously be copied as well.
I started looking at how to update the FireRating sample to a cloud-based implementation making use of one single global mongoDB NoSQL database to hold the data for any number of Revit projects.
For the sake of compatibility and completeness, I retain the unused level and tag data.
I will obviously replace the element id of the door instances by their unique id; being unique, we can use it across projects.
Here are the explorations I made so far:
Here are the plans for the next steps, which – actually, hopefully, as usual, as always – will take a lot longer to explain and document than to implement:
Keep an eye on The 3D Web Coder to see how we address these steps.
Daren Thomas, author of the Revit Python Shell, points out a new and exciting project, providing full web-based REST API access to Revit and the Python Shell:
I finally finished an article that I spent a lot of time working on, embedding a web server in Revit – the initial idea was born two years ago!
This post (including full code on GitHub) explains how to turn Revit into a web server with a REST interface using the RevitPythonShell!
I used this technique in two projects already and am quite pleased with the results – two papers I wrote are based on the ability to access BIM data from a scientific workflow tool (like Kepler or VisTrails), and having a REST API to drive the functionality makes this a snap!
I used your idea for exporting a schedule to CSV as an example to discuss the technique.
Also, this can very easily be implemented in C# too, as it uses .NET classes for all the heavy lifting.
Read the article for the full story and all the links.
Thank you very much, Daren, for this exciting and powerful project!