Get elements in room using Dynamo

Hello

I’m currently working on a project where I need to use Dynamo to analyze elements in a room. My goal is to have Dynamo identify the room name and add it to the Comments parameter.

I’ve already made an initial attempt with Dynamo, and although I didn’t encounter any warnings, I noticed that only the door and one generic model in Revit have the room name in the Comments parameter (In blue). However, the interior wall and another floating generic model don’t have anything under comments.

Could you please take a look at my Dynamo scripts below and let me know if you spot any issues that might be causing this? I would really appreciate your help. Thank you!



Can yo try using the Room.IsInsideRoom node to see if that returns more resuults @AAbuYosof ? :slight_smile:

image

Thank you getting back to me. @solamour

I have never used Room.IsInsideRoom not sure if my connection is right ?

please see below


You need to attached your Revit Rooms (With the Green Element ID after them) into the room input, and that should do it!

So from your “Categories” (Pulling Rooms) then your “All Elements of Category” → Plug this one in.

Having little hard time understanding. @solamour

What’s (With the Green Element ID after them) ?

This one :slight_smile: The green Element ID’s are what the Elements in Revit are trackable with (Along with GUID’s) and you can click on them in Dynamo to Zoom to that element in the Revit model if it’s visible in a view.

RoomAtPoint might be more useful still. Not sure if there is an out of the box node for it, but if I recall correctly Archilab has one. :slight_smile:

2 Likes

Thank you for the explanation.

Having the Same problem. No warnings, then I noticed that only the door and one generic model in Revit have the room name in the Comments parameter. The interior wall and another floating generic model don’t have anything under comments.

It doesn’t appear that you have selected the interior wall at any point. Generic model, floors, and doors are the only categories you are testing in this graph… and I have some concerns on the general strategy here.

Think of a corridor wall where you have a whole bunch of rooms on the other side of it. The wall belongs to the corridor, but also to every room on the opposite side… the current graph strategy only allows writing a single room name to the comment parameter, so if that wall is found to touch 50 rooms, only one of the 50 will be tied to the wall. Similar issues occur with doors and windows, though to a lesser extent, but more impactful would be floors, ceilings and roofs. I have seen many a project where one floor slab intersects every room on the floor… might not be much value in that.

The next concern comes into play with having to duplicate work. Many of the objects which you are working with (generic models, doors, and pretty much every loadable family) can report their room already once the Room Calculation Point is enabled. Once this is done you can quickly pull the room property of the element to get the data you are after, without any intersection tests or geometry conversion. That will take stepping into Python, but if you work on projects of significant enough scope that is inevitable.

The last issue is that the objects feeding into RoomAtPoint and Geometry.DoesIntersect are all location geometry, but that geometry isn’t necessarily a point, and as such you may get false positives, multiple false negatives (ie: walls) or multiple results.

For the system families (walls, roofs, floors, columns, etc.) I recommend utilizing something like Room.Boundaries to pull the bounding elements from each room, and reverse the association so each element has the room associated to it rather than the rooms having the elements.

2 Likes