Detecting doors and windows in areas

I’m trying to detect doors and windows ‘touching’ or ‘intersecting’ with areas.
Areas don’t have any ‘3d space’ to compare against, so SteamNodes’ GetSurroundingElements doesn’t work.
I want to put the ‘Number’ parameter from the Area into a ‘touching’ doors and windows parameter.

Hi @C.W_Bronstijn

Could you show us where you got stuck? Drop some images or files. Thanks :slight_smile:

Sorry for the delay…

I’m looking for a custom node (or a way to do it myself) to detect what area the door/windows might belong to (ie touches within some threshold distance). But because areas don’t have any 3d geometry in itself i cannot ‘compare’ them. Rooms and doors/windows relationships can be detected by that node ‘GetSurroundingElements’ but Areas have to be decomposed into the boundaries, recomposed into curves, into polycurves, into a thickened surface that can be checked with the boundingboxes of the detected doors/windows…
I’m thinking there should be a simpler way, like projecting the boundingbox (or the actual geometry) of the detected doors/windows onto the level of the area and cross-checking that (saves the step of creating 3d geometry of a flat areaplan)… Aftre that the excercise of reading a parameter and putting that into another is not a problem (i would think), but i’m kinda stuck at the differences of rooms and areas.

Am i making sense?

Maybe a step in between, can i cross-reference the rooms and areas?
So i can put the room a door/window belongs to (from-room) into an area-parameter?

Hi @C.W_Bronstijn

Its possible to get geometry from Areas.

Are you looking to detect doors and windows separately or both together?

Here is how you can get the doors.

1 Like

Thanx, Kulkul.

Your answer kinda solved it, but somehow the 'Lunchbox Area Element Collector is not working for me (Revit 2017.1 - Dynamo 1.2 - Latest Lunchbox), i’m only getting null-lists. My way around it is in the capture, as is the rest (for now) because via your way i’m getting all jumbled up areas and door/windows combinations with most doors/windows connected to the wrong areas.
That may be the list.map/list.anytrue combination messing up, so i might dive into that, the rest looks promising.

One thing your capture showed me is that i don’t have to convert the doors and windows to boundingbox solids (saves a step or 2 and is more exact for detecting).
However, i still need to detect if it touches/belongs to that specific area. Maybe instead of the solids i could (mis-)use the ‘Room Calculation Point’ and see if the from-side lies in my area-solid. That would also take care of that stupid curve.offset (the threshold) because the that offset sometimes needs to be so big as that other doors/windows get detected as lying in that area.

This is where i’m at now…
And i will squash the double area conversion into one later on, but for now it reads better for me.

1 Like