Revit connector: Levels and Spaces

Features & Ideas
#1

Hi Speckle team,

Within our company, we’re applying Speckle to share Revit space data. We then add requirements and run calculations with this data, and send the outcome back to Revit, mostly stored in (Revit) parameters. We noticed some issues or possible improvements for our workflow, regarding Space and Level objects.

Spaces
Generally we get a model from the architect, in which we have to add the spaces, which are then used to go through the above-mentioned workflow. Currently, when we get a new, updated model from the architect, we are required to do a full new iteration of the described workflow (which can be time-consuming). Namely, the space data is being matched based on applicationId. So with a new model and new spaces, the previously calculated spaces do not match anymore. Because the updated model generally has a lot of similarity, it would be nice if we could match most of the ‘old’ data with the new spaces in Revit. This could maybe be based on matching name and/or number for spaces. In the ideal situation, we would be able to indicate how we would like to match the spaces in Revit with the spaces from the stream, e.g. based on applicationID, name and/or number.
An additional problem resulting from the above, is that ‘unmatching’ spaces are by default added to the Revit model. So if we essentially have equal spaces (same place, name, number, etc.) on Speckle and in Revit, but with a different applicationId due to renewal of the spaces, the space from Speckle will be added in Revit on top of the existing Revit space, resulting in two basically equal spaces in one place. Also here, we would ideally have more control, being able to indicate if we want new spaces to be placed, if an existing matching space could not be found.
Lastly, having a simple overview in a pop-up window of the matched spaces that were received from Speckle would be nice, which could also include any new spaces that were possibly placed. I do realize that we have quite a specific workflow that we would like to support here, and can imagine that this is maybe not fully aligning with your current development goals and vision. But also that would be good for us to know. What is your opinion on this?

Levels
We also noticed an issue with the levels. During conversion from our own format, we added some Levels without an elevation. These ended up overwriting our base level (z=0) within Revit. It seems that this is due to this line below, where the speckleLevelElevation is converted to a double, which will convert Null to 0.0.

image

First of all we should take care that these Levels are properly defined of course. However, it seems undesired that a Level without elevation is by default added at z=0, probably overwriting an existing level in a lot of cases. I think without an elevation, the Level should not be placed at all.

Would be nice to hear what you think, Speckle developers as well as the community, thanks!

1 Like
#2

Hey @Rob ,

Thanks for sharing these use cases and for the suggested features!

Spaces

  • matching: matching by name/number makes sense but it comes with its own issues, what if someone wanted to update a space name or number? This would get tricky. So, ideally the matching would happen before the data is received in Speckle. But let’s explore a few additional options: from where are you sending these spaces to Speckle? If it’s GH/python we could add a parameter that toggles how the matching is done (we have the same for Levels at the moment with the referenceOnly prop). Another option is to add an “Advanced Setting” in the Revit connector UI that lets you toggle the same on receive.

  • receive behavior: we have recently added support for a "receive mode" that could be extended to support your needs. For instance we could add an “update only” mode that only updates matching elements, without creating new ones. WDYT?

  • preview of changes: it sounds like something that would be addressed by this pending issue

Levels

The elevation property on levels is a double which by default is not nullable in C#. I don’t see good reasons to change it, unless people have a good use case for sending levels without elevation :wink:
So it’d be better to add a check/constraint on your end if possible?

#3

Thanks @teocomi, very useful!

Spaces

  • Agree that matching by name and number also has its issues, therefore having the option to choose would be great. Regarding matching before/during sending to Speckle, that would be possible. We’re using Python, so that definitely gives some flexibility to match based on different attributes. We already do a similar thing, where we compare IDs of our locally calculated spaces with IDs of spaces in the original commit on Speckle. However, that would require more steps to sync the data properly. Therefore, having a simple attribute to indicate how matching is done would definitely be preferable. This would already go a long way in accommodating a workflow that is more controllable. The last option (advanced settings) would probably be the best, as it would give the most control to the users to match any commit the way they want when receiving.
  • The “update only” mode sounds great, would be very helpful.
  • …and would be even more powerful with the preview of to be received data. That would nicely show the user the spaces that can be matched. Then, if you would also have the “Advanced setting” of choosing your “matching attribute” at receiving, it would be perfect. User can then play around and check which option gives the most desired result, or even use different matching options subsequently.

Levels
Must admit that I don’t have a strong use case for levels without an elevation :sweat_smile:
We can definitely prevent this behaviour at our end.

1 Like
#4

I can also see added value in a similar approach for other objects as well. For example, try and match objects based on geometry, which would be very useful when you have two models already created in different software packages (Revit and a structural analysis software).

Before you can update the two models one way or another (Revit → Structural software or visa versa), the existing objects should be matched. It would be great if Speckle could provide a functionality to compare the objects based on geometry and match them if they are within a certain tolerance. I think this needs to happen only once and then the matching based on ApplicationID can be used.

Just sharing this as an idea. If only there would be a hackathon coming up and someone had the time to explore this :stuck_out_tongue: (not sure if the team I’m in will look into it, we’ll decide later this week)

2 Likes
#5

Hi Matteo,

Another addition to this issue.

I was busy solving the problem with Levels without elevation I described above. For that purpose, I tried the referenceOnly attribute of RevitLevel you mentioned. That should find a ‘matching’ level within the model based on Space name.

Unexpected to me was that when choosing to match on name, it will still try to match on elevation when name matching fails, see ConvertLevel. To me it would make more sense that in that case, an entirely new level would be created, without checking the elevation. Then, with later implementation of the updateOnly receive mode, a user could decide to match only on level name, and not create a new level when the name doesn’t match.

I still agree that levels without elevation are a strange thing. However, also the matching on elevation when explicitly told otherwise seems unwanted to me. What do you think?

1 Like
#6

That’s fair enough! Submitting a change now :slight_smile:

1 Like
#7

Hi @teocomi,

Noticed that your Revit docs already mention the ‘update only’ receive mode with a ‘coming soon’, happy with that! Does the same go for the previewing functionality? Can imagine that this would be more time-consuming, and couldn’t find it on your public roadmap. Sorry for the impatience, but believe these features could be of decisive value for us :innocent:

#8

We are actually scoping down the preview functionality alongside an improved reporting, we don’t have an ETA yet but stay tuned :slight_smile:

1 Like
#9

Sounds good, thanks!