I am currently engaged in a large-scale project where we utilize Navisworks on a weekly basis for clash detection . Our current workflow involves exporting clash reports as XML files, processing them locally in Power Query, and visualizing the results in Power BI. While this process works, it involves multiple steps that could be streamlined .
Given the capabilities of the Navisworks Connector in alpha, which is an exciting development , I see a potential for workflow improvement. My suggestion is to enhance the connector to support direct transmission of XML clash result data into Power BI through Speckle. This feature would reduce the steps involved in the reporting process, cutting down on time and potential errors associated with handling multiple data conversions.
From the information available, the Navisworks Connector currently supports basic 3D geometry node conversions and is planned to expand to include features such as unit support, full property translation, and correct Y-Z orientation. I believe adding functionality for directly handling clash reports could be a valuable extension, especially for those of us relying on Speckle for managing AEC data more efficiently .
This direct integration would not only save time but also allow for more dynamic data handling and visualization capabilities within Power BI, providing real-time insights and enhanced data interaction for project stakeholders .
I understand that the connector is still in its alpha stage and appreciate the complexity that new features entail. However, I believe this addition would greatly benefit users like myself who are looking to optimize AEC data workflows through Speckle .
Looking forward to hearing your thoughts and any further updates on this
Thanks for the suggestions. As a veteran Navisworks jockey a version of this workflow is definitely on my personal wish list for development roadmap.
A version of this is already possible as the xml reports from Navisworks already include elementIds as does the data you can export.
The way I’ve gotten best results are to youse the advanced option on send “aggregate data to first object” and then in PowerBI perform a data join between the xml and the speckle Navisworks data.
—-
Are you already using the Navisworks connector for Speckle? A number of the early issues you mentioned have been resolved already (YZ flipping, full properties export etc.) give it a whirl. Be warned Navis models can be heavy start with smaller selections.
The next step for us will be to cross check what options people have used and make this the new defaults as we progress out of alpha.
Thank you for the insights and suggestions, Jonathan!
It’s great to hear that enhancements to the Navisworks connector align with our needs and are already part of the development roadmap. I’m particularly interested in your tip about using the “aggregate data to first object” option for better integration with Power BI. I will definitely give this a try.
I’ve had some challenges in the past with sending Navisworks objects directly, especially when dealing with our larger models that are divided into segments— largest .nwd being around 20GB split into six parts. These initial attempts were somewhat problematic, but it’s encouraging to know that many of the early issues have been resolved.
Based on your recommendation, I’ll start experimenting with smaller selections and progressively scale up. This approach seems promising for better integration with our existing Power BI workflows.
Looking forward to more improvements as the connector moves out of alpha, and I’m keen to see how these developments will streamline our processes.
. Our current workflow involves exporting clash reports as XML files, processing them locally in Power Query, and visualizing the results in Power BI. While this process works, it involves multiple steps that could be streamlined 
.
, I see a potential for workflow improvement. My suggestion is to enhance the connector to support direct transmission of XML clash result data into Power BI through Speckle. This feature would reduce the steps involved in the reporting process, cutting down on time 
and potential errors associated with handling multiple data conversions.
.
.
.