To push element type parameters into shared parameters for rooms

I have a model file and an annotation file. In the model file I am modeling the elements and in the annotation file I am linking the model file into it and I am putting rooms and annotations into it.

So basically what I want is similar to roombook extension. To make dynamo read the rooms in the host file and then read the model elements in the link that are touched by the room. Then push the element properties into room tags. (the room tags should give me room number, area, ceiling, skirting, wall, finish floor codes.

Is this possible?

Hello again,

Any thoughts?

Possible? Roombook did it right (or something similar)? So, yeah, should be doable… but you gotta start it out.

Ok, after a while I figured what I want is much simpler than other solutions to similar problems in the forum. This is working for me completely.

There is a link file which contains only rooms. The solution reads from the link file the rooms and writes the number and name of the rooms to the model file. Btw the solution is running through the model file not the room file. As far as I can understand dynamo cannot write into link files.

Any way, after the room names and numbers or any parameter that can be given to the room is read, they are written to the selected model category, in my example furnitures. I’ve tried it also for floors and ceilings.

I don’t know if room height is of importance. Rooms are not 3d entities, but in sections do they have to touch the floors or ceilings or for walls do I have to change the room calculation from wall finish faces to mid cores?

I have to experiment more. Thanks to Greg and Kulkul.

After a while I’ve realised that the numbers and names come in incorrect order. What kind of sorting do I need?

First you need to get elements(furniture) inside rooms(linked file) then you can set parameter to your furniture elements. One of the possible way is to use “Tools.GetSurroundingElements” from steam nodes package to get elements inside rooms. You need to upload the files online (Dropbox, Google Drive etc) and share the web link here. That would allow a lot more people to study your file and provide suggestions and solutions.

These are my files. Sorry for delay. The file sizes are huge. INA_ARCH_TB_B_EXPORT contains rooms and INA_ARCH_TB_B is the model. So I’m linking the INA_ARCH_TB_B_EXPORT into INA_ARCH_TB_B. What I don’t understand is when I crop the model delete many things and reduce is 2-3 rooms, the code works. But if I have a couple hundred rooms, everything goes crazy. Please help.

After a while I came up with this. I does work perfectly, but when there are 1000 floors and 1000 rooms then it crashes my revit. Is there a way to simplify or optimize this code? I think geometry.doesintersect with cross checks maybe a million possibilities. Once @Kulkul mentioned to use keys id’s but I couldn’t solve that.

Tool.GetSurroundingelements is working not so good. Although you limit its category to floors, it sometimes shows also walls in output. I think it has bugs. (in element outputs dynamo gives element ids in green, when I search it, I select walls)

Any ideas to optimize this?

1,000 floors!?! Wow. Sounds like you’re running out of memory. You’ll probably need to break it off into smaller chunks. 200 at a time, maybe less. Use a GetItemAtIndex with a range for your index (0…199 will give you the first 200, for example). Then close the definition to clear it from Dynamo’s memory and rerun with 200…399 (or whatever) until you’re done. You can probably set this up with DynamoAutomation (a Package) as well to do it in batches.

you could try writing a python node which directly accesses the revit geometry and creates a bounding box to do the intersection check there instead of using the Dynamo version - this is doing a conversion from Revit Geo to Dynamo Geo and then doing a pretty giant loop of intersections … 1000 x 1000 = 1,000,000 (million) intersections (thats my guess from what you have said your input data is).

Or dont do the intersection check on the geometry - create a bounding box from the geometry and check if those intersect, or other strategies like this…

Does the initial geometry conversion fail with element.geometry or only the intersection check?

Nothing fails with geometry intersect. It runs with smaller chunks. But if
there is 2 floors in a room, then the sequence gets scrambled. Don’t know
why. I will try to limit the code for elements in active view and do it
sheet by sheet. There are 55 sheets A0 1:100 in each floor and we have 9
models. (for each floor) Geometry does intersect with short and long lacing
doesn’t do what I want, only cross lacing works.

Sounds like you’re dealing with nested lists and getting them un-nested at some point. You’ll need to maintain the nesting through out to make this work over multiple floors (assuming you’ve organized the data by floors in the first place).

It will be a least 3 levels deep (Floors - Rooms - Elements)

I think is needed two nodes “List.Create” here (red dots):

Hello I would like to know what happened with this solution, what I detected is that there is no way to correctly insert the parameters in the wall through the reading of the room, it is very inconsistent, I want to retake the initial idea of ​​taking the information of the elements to attach it to the room
regars

Sorry, couldn’t advance with it. What we did at the end was to use a dozen of juniors to enter the room numbers into floors and ceilings. Do you mean by walls just wall claddings right? Because the walls don’t belong to a room.

Some guy on youtube did it, will update this message if I find him. But he specifically mentioned that if there are two or more floor pieces in the same room, then the sequence gets screwed.