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:
- The FireRating Revit SDK sample
- FireRating data structure
- FireRating in the cloud
- Revit and the Revit Python Shell as a REST API driven web server
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 FireRating Revit SDK Sample and ADN Xtra Labs
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:
- Create a shared parameter to hold a fire rating value for all door family instances.
- Export the fire rating for all instances to an Excel spreadsheet.
- Import the (possibly modified) fire rating values back from the selected Excel spreadsheet into the project and update the respective shared parameter values on all instances.
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:
FireRating Data Structure
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:
- Element id
- Fire rating
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.
FireRating in the Cloud
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:
- My First Mongo Database – installation, tools, and storing the door instance data.
- Implementing Mongo Database Relationships – RVT project identification, storing the project data and handling the door-project relationship.
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:
- Add a REST API to populate and query the database programmatically.
- Implement a Revit add-in exercising the REST API from C# .NET.
- Re-implement the complete round-trip FireRating Revit SDK sample functionality.
Keep an eye on The 3D Web Coder to see how we address these steps.
Revit and the Revit Python Shell as a REST API Driven Web Server
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!