Thread: Door From/To Room Value in Schedule

BTW.

I had a client ask me this question about linked door schedules last week. I had a very quick 15min look and couldn't find an easy way to do it, and I am a bit pushed to spend any more time on it at the moment. He has since told me that another developer is looking into it for him and they hope to have a solution for him next week so it will be interesting.

Thanks Phillip. That's very kind of you to let us know. To be honest I am not expert like you or other API gurus here but I did try using Start, Commit, and End transaction and couldn't get it to work. And after some google search and reading 2012 API guide I concluded it can't be done.
Please let me know if you find a solution for this.
Regards

Originally Posted by pfaudler

Please let me know if you find a solution for this.

That sounds like a question for Tammik.

I never tried to open linked files and alter their models, but it shouldn't be impossible.

Revit 2013 version has been uploaded.

I don't know anything about the API side of this but you can select a door's To / From in a schedule regardless of the direction the door is actually facing. It does require manual work but set it once and you're done.

The problem there is, is that when you flip the door to face the other room, the schedule won't update... Which can be a big problem in coordination when you need them to. This API does update them.

For instance:
Door swing direction in Holland CAN be mandatory in a certain way depending of Room usage (bathroom and toilet doors need to swing into the hallway), whether they are part of a fire egress route, and how big the floor area is depending on the door, and so on.

In the bathroom example wouldn't the door still belong to the bathroom but swing into the hallway. If you place a door so that the swing is toward the hallway the To Room value is the hallway. If you place a door so the swing is into the bathroom first the To Room is set to the bathroom. Flipping the panel out toward the hallway leaves the room assignment intact, To Room is still the Bathroom. Are you saying the To Room value is meant to be the Hallway instead? Either way, it is easy to define the correct orientation, just initially place the swing toward the room that is supposed to get the To Room reference. Seems to me the app is just as likely to get it wrong depending on whose criteria is in play?

In Holland is the To Room setting always where the panel swings toward?

Originally Posted by Steve_Stafford

In the bathroom example wouldn't the door still belong to the bathroom but swing into the hallway. If you place a door so that the swing is toward the hallway the To Room value is the hallway. If you place a door so the swing is into the bathroom first the To Room is set to the bathroom. Flipping the panel out toward the hallway leaves the room assignment intact, To Room is still the Bathroom. Are you saying the To Room value is meant to be the Hallway instead? Either way, it is easy to define the correct orientation, just initially place the swing toward the room that is supposed to get the To Room reference. Seems to me the app is just as likely to get it wrong depending on whose criteria is in play?In Holland is the To Room setting always where the panel swings toward?

Nope, it isn't. That's my whole point. The workflow is crooked because of the sense of direction it implies:
- Upon placement the T/F values inherit the direction of the door swing. This implies (as do the 2 parameters) a sense of direction. From one room to the other. This, imvho, has nothing to do with the room a door belongs to for documentation purposes.
- The door swing direction has nothing to do with the room a door is assigned to. In the bathroom example, door swing is towards the hall, but the door still belongs to the bathroom. A bedroom has the door swing typically into the room. And this door also belongs to that room.
- When working in preliminary design phases Revit has the Coarse detail level. You can assign different representations to doors, walls and other objects. It is customary to NOT show door swing in the Coarse level. But how am I going to place it correctly if it's not showing the swing?
- I (mis)use this parameter for a lot of things... For instance to define airflow in ventilation systems. I created some simple Door/Window category families that define the airflow between rooms through gaps under a door or ventilation screens in windows. They work independently from door swing direction or window orientation. But flipping those (as happens a lot when "designing" the air terminals needed, has no effect on the schedule.

It's just not logical to me. I could see an extra parameter in which you define to what room a door belongs. But the only purpose this has is in the tagging and documentation of the door for the construction process. The T/F parameters are way beyond that. Besides: if the only value is to show which room a door belongs to, what's the meaning of having 2 parameters? (and especially so with windows which typically only use one)
But I remember to have butted heads with you on this on multiple previous occasions... And with Factory workers too. We just don't see eye to eye on this one...

The feature is based on a different user story as they call it. As it happens it is one I'm the most familiar with working here in the States. I see your point about door swing not really defining the relationship.

Yeah I know... too bad they don't just listen to me solely...