Here is a graph that I’ve thrown together that pushes the Revit Space number into the COBie parameter “COBie.Component.Space” for elements that are within the Space, including elements above the ceiling.
Note that in order for this to include the elements in the area above ceilings (i.e., mechanical and electrical equipment), your spaces must use the “Upper Limit” parameter on your spaces to include the elements that are within the ceilings above the Space. This hasn’t been fully tested, so if it doesn’t work for your project please let me know in the comments below.
Open the model which contains the elements you wish to populate the COBie parameter (e.g., MEP model).
Launch Dynamo and open the graph linked at the bottom of this post.
In the graph, choose which categories you would like to push the space data into. Modify the List.Join node if you need to add or remove categories from the list.
Set the graph to Automatic (for an easier workflow)
Use the Select Model Element node to pick a space individually.
Continue selecting spaces as needed to populate element COBie space data.
Under the Hood
This graph first gets all elements of the chosen categories and then gets the BoundingBox of a space.
It then filters out the elements whose coordinates are not within the selected Space’s BoundingBox.
Finally, the graph pushes the Space’s “Number” parameter value into the “COBie.Component.Space” parameter.
The unique challenge here was for MEP elements that are above the ceiling. To solve this, I use the Space’s “Upper Limit” parameter to include the ceiling space above the Space.
A new BoundingBox is created using the new MaxPoint from the “Upper Limit”.
I haven’t tested this on complex spaces, so if this doesn’t work for your project, please let me know in the comments below.
This graph could be modified to iterate through all spaces, but I haven’t had a chance to do so. Please, if you end up modifying it to do so, please share the dyn in the comments below so that I can update this post and share with our readers.
To supplement the BIMxHTML Dynamo package, I published a second package called BIMxDB. This package will contain several custom nodes for exporting Revit data to different types of databases.
For now, my focus is SQLite and the current node that is in the package is Export.SQLite.ParameterData.TimeStamped. This custom node creates a table in the SQLite database specified as an input.
The table is named with the Model Category (input #1) and suffixed with a time stamp in Unix time format (e.g., Ducts_1503598277.39).
I see this type of workflow being useful when plotting line charts of quantities over time or comparing changes between model versions. I will be using this on my next project, so stay tuned for a case study!
In the sample below, a simple graph demonstrates the usage of the node by taking a single model category’s elements and exporting all parameter data to SQLite.
It looks like there has been some interest in the BIMxHTML Dynamo package and its encouraged me to develop some custom nodes to simplify the display of Google Charts using pure Dynamo.
The Custom Nodes
Download the sample files below to get a good example of how to use these nodes. Essentially, they output an entire web page and as of today the intent is to use them in the iframes of a dashboard.
Data Set – Quantities of Family Types.dyf
Use this node to build a dictionary of family types of any given category. The output is actually a list of sublists which contain the [key, value] pairs as [family type, quantity]. For example: [Diffuser24x24, 17].
This node is helpful to use for the input of any of the Google Chart nodes.
Generate Web Page – Google Pie Chart.dyf
Creates the complete web page to display a responsive pie chart based on the Google Charts API. The intent for the HTML file is to reference it in an iframe for a dashboard (more on that to come).
Refer to the sample Dynamo graphs below to get a better idea of how to use these nodes. Dashboard-Mech.html is currently the best example because it displays a pie chart, a bar chart, and a table – all generated directly from Dynamo.
All of the excitement revolving around generating dashboards using Power BI made me wonder: Can we leverage Dynamo to create web pages that display data directly from a Revit model? The goal would be to create a powerful, free alternative to generating web-based content using simple HTML code.
Needless to say, the gears have been turning and I have been experimenting. With that said, I have published my first Dynamo package, BIMxHTML, which will eventually have several nodes to display content on a web page using very basic HTML. I have been playing with Twitter Bootstrap and Google Charts so far.
For now a single node is included in the BIMxHTML package: Generate Web Page.
I have a sample model and graph for you to see the node in action available for download below.
Sample Files Explained
There are a few sample graphs included in the download below. Please keep in mind that these are extremely early examples of the possibilities of using Dynamo to extract Revit data and output HTML for display in any modern browser. Currently, I have been experimenting with a combination of Twitter Bootstrap and Google Charts, but if you have any suggestions on other frameworks or analytics tools, please make a suggestion in the comments below.
Table Sample.dyn (TableTest.html)
Creates a list with parameter values as sublists.
Using Python, the HTML code for a table is generated using each list item as a table row and each sublist item as a column value. Note: a custom node will be added to this package to handle this in the near future.
Finally, the Generate Web Page node from the BIMxHTML package creates the entire web page’s code and then writes the code to an external HTML file.
Google Charts – Pie Chart.dyn (Air Terminals.html / Ducts.html)
Creates an HTML page containing a Google Charts pie chart displaying the quantity of family types per category.
A sample Bootstrap layout which uses iframes to display the pie charts generated from Google Charts – Pie Chart.dyn.
Would these tools help you with your workflows? Do you have any suggestions on how I can improve on these? Would you like to help contribute? Please leave your questions and comments below.
Tonight (yes, I am working on a Friday night), I ran into a new issue that I thought the community might be interested in. I linked an IFC into Revit which was exported from AutoCAD MEP.
The issue is, I could not see any of the duct.
Autodesk posted a solution to the problem that unfortunately did not work for me. After a little experimenting, I discovered that if you switch to a reflected ceiling plan view, the duct work from the IFC was visible in my view.
One of the biggest challenges of dealing with large Revit models is working with outside consultants’ linked Revit models. You may need to use a linked view to easily match said consultant’s floor plan views. In that case, you should use the By Linked View V/G setting of your RVT Link. The problem you will face is that you cannot control the linked view with a View Template unless you have a View Template for each level.
I’ve seen a number of projects that actually had a view template per level. Don’t do this! In my opinion, this is improper usage of templates because if you have to make a change to a template, you would actually have to do it several times (once per floor). Keep in mind that for large Revit projects, the less templates you have, the better.
So, how would you solve the issue of having linked models with their Visibility/Graphics set to “By Linked View” on multiple levels without managing a template per floor?
First of all, in your View Template settings, uncheck the V/G Overrides RVT Links.
You cannot use this setting if you have linked views that point to specific levels unless you have a view template for each linked level.
Second, create a view template that ONLY controls the V/G Overrides RVT Links.
Think about how you would like to apply the linked views in batch and set your linked view in that template. For this example, I needed to create a template per level.
I realize I seemingly contradicted myself by having a template per level, but keep in mind that these templates are never assigned to views themselves – we will use them to apply the RVT Links settings only. So in the rare event that you need to changed your By Linked View settings, you are still saving an enormous amount of time by using these templates to manage your “backgrounds”.
Lastly, apply the template properties to all views that need to display the linked view in your template.
Select the multiple views that you need to have the same linked background (most likely every view per level) and right click and select Apply Template Properties from the menu. Note that applying a template’s properties to a view does not assign the template to that view. It will only apply the properties that aren’t controlled by the assigned template.
Power-user tip: Change your Project Browser organization to group the views by Associate Level so that you can easily select all views for each level easily.
This gave me the clue that the architectural model was a detached central model. This means that the model has been detached during an eTransmit process.
It is hard to find technical information regarding the state of these models. From what I’ve figured out, the model is in a state where it is technically “read only”. So if the linking process requires accessing or revising anything in the linked model, you will get an error. In this case it was an issue with permissions to edit shared coordinates.
Let’s talk a little about Plan Regions in Revit. In a nutshell, this tool helps to show areas of a View that may need to deviate from your view’s View Range. Aside from the common uses for this in architecture, mechanical designers can actually get their risers to display properly when using a vertical elbows.
Mechanical and plumbing Revit Designers have undoubtedly run into issues with their ducts that turn vertically if the elbow is outside of the view’s View Range. Revit does not cut through the elbow properly, if it cuts through it at all. Note the image below is missing the “X” within the riser to graphically designate which system the duct is on.
The issue is caused by the View Range settings for your view. Don’t fuss with the View Range settings for the entire View because tweaking View Range for one riser can be catastrophic for your the rest of the elements on your View.
The Solution: Use a Plan Region
The steps below outline a simple workflow to fix this issue. The goal is to create a Plan Region that encompasses the shaft’s view range requirements. Note that this technique also works with pipe elbows that do not graphically show the proper up or down symbol.
First, take note of the elevations that you need where you need to adjust your view range for the Plan Region.
Next, go to View > Plan Region and draw a shape around the area you would like the View Range to effect.
Important: Your plan region needs to encompass the entire riser for this to work. If the outline of your Plan Region overlaps the duct, it will not be effected.
You may want to extend your Plan Region a little further out than the duct itself. Note that the Plan Region outlines do not print.
Now we must adjust the View Range for the Plan Region. With the outline of the Plan Region selected, go to the View Range setting in the Properties window.
Adjust your View Range accordingly based on your measurements from step one.
The riser should now display the appropriate symbology within the duct that is turning up or down.
Bridging the gap between you and your building information model.