PDA

View Full Version : RoomTo, roomFrom not updating?



GuyR
2004-11-05, 06:20 AM
I've been playing around with the room association scheduling both in Revit and ODBC.

If you place a window in a room the roomto/from is set based on the internal/ external face (as expected). But if you flip face the window the schedule doesn't update.Bug? same via ODBC, doesn't update.

Secondly how do you do a query in a database using roomto/from? The Windows/doors tables don't seem to have an instance field for linking to the room association tables.

Thirdly :-) What is the difference between the roomassociations table and fromtoassociation ? When I export to the database roomassociations is empty, only roomFromTo has records(as expected)

Cheers,

Guy

beegee
2004-11-05, 06:35 AM
Re your first question, ... yes, that has been noted as a possible bug.

Refer this thread. (http://forums.augi.com/showthread.php?t=9621&highlight=schedule)

LRaiz
2004-11-05, 08:23 AM
From and To for doors/windows currently are not related to neither exterior/interior sides nor to a swing graphics. This is done deliberately after a consultation with in-house domain experts. Developers were told that the notion of From and To is independent from swing direction and that Revit should not impose any rule besides checking that From and To refer to rooms on two sides of a wall.

GuyR
2004-11-05, 08:47 AM
Cheers Leonid,

So it's not a bug.... It does seem to base the initial direction on the windows int/ext face so I guess it's important to get that right to minimise rework.

Is the roomassociations table that's exported for future functionality? I can't see what it stores? Every export so far it has been empty.

Guy

beegee
2004-11-06, 10:11 AM
It appears to me that door placement is initially related initially to door swing graphics.

Whenever I place a door, Revit always correctly identifies that the room the door is swinging INto is the TO ROOM and the room the door swing is away FROM is the FROM ROOM. This happens without fail in my experience .... and is the correct definition, AFAIK, despite what the domain experts are saying.
I know there are situations where the user may wish to override the predetermination of TO and FROM. Such a case occurs when a door swings out from a classroom or hospital room into a corridor, ( via an alcove possible ) where it is more convenient to designate the door as belonging to the room rather than the corridor, ( which may have many doors opening into it, ) and where the door may need to be keyed to the room type, rather than the corridor type. In these cases, it should be possible to allow the user to over-ride the original determination.

Its only when the door is flipped that the schedule fails to update. So it seems that the intelligence to determine TO and FRO rooms is there initially, but is not enabled when a door is flipped.

I think this needs to be reconsidered by the developers.





From and To for doors/windows currently are not related to neither exterior/interior sides nor to a swing graphics. This is done deliberately after a consultation with in-house domain experts. Developers were told that the notion of From and To is independent from swing direction and that Revit should not impose any rule besides checking that From and To refer to rooms on two sides of a wall.

gravelin
2004-11-06, 11:16 AM
I think this needs to be reconsidered by the developers.
I agree with this.
If we need the change the association, no other way than remove the door and replace it changing the face of the wall when pointing.
maybe an option in the right click ?
depending or not of the representation...

ronjon
2005-01-11, 05:45 PM
I agree with GuyR's and others that these properties should be associative and parametric. GuyR provided a window example.

Here's my Door Example:

I like creating a working Exterior Door Schedule to see all exterior doors in one listing to verify that they have the right hardware and accessories. It is unnecessary to create another parameter to track this behavior.

The rational way to do this would be to look at the ToRoom parameter (assuming it would mean swing direction). Obviously, if the room value is null, then it must be an exterior door.

Other related topics:
Refer to my thread on: Families: Rule Based Architecture in wishes.

Example: Rule: All exterior doors must have a closer. This could be a switch that links the ToRoom parameter to the closer parameter checkbox in the door hardware set schedule.

Thanks for listening!

aaronrumple
2005-01-11, 06:12 PM
This is done deliberately after a consultation with in-house domain experts.

At some point you have to quit listening us stupid architects... Two decades for us to come up with a layer standard? About time we had some standards forced on the industry.. ;-)

LRaiz
2005-01-14, 04:09 PM
I think that the trick is in figuring out the right way to listen to architects. You folks have a different distribution of strengths between visual and verbal parts of your brain. Therefore seeing and understanding drawings often reveals more than listening to words. Besides, drawings are the language of architecture.

When we studied the drawings it appeared to us the even though in many cases the notion of from and to indeed corresponded to the direction of door swing there were a number of exceptions. At the time the team decided that instead of figuring out and implementing necessary concepts it was better to leave the from/to decision up to end user and spent development resources elsewhere. This decision may need to be revisited in the future.

bowlingbrad
2005-01-14, 05:55 PM
Maybe I can add something...

Exiting. A door that is designated as an exit (required means of egress) must swing out of a room in the direction of exit travel. Revit doesn't / shouldn't know which direction is in the direction of exit travel. It could know that this door is an exit door (parameter?). This could help in the scheduling process to identify to us that this door may need to be rated, have special hardware, etc. We, as architects, still need to figure out proper exiting and FROM/TO directions as well as hardware. My vote is to leave this alone. I would, however, like more standard parameters pertaining to function.

bclarch
2005-01-14, 09:50 PM
Maybe I can add something...

A door that is designated as an exit (required means of egress) must swing out of a room in the direction of exit travel.
Just to add another wrinkle to automating the process, even the above requirement only applies to rooms with 50 or more occupants.

aggockel50321
2005-01-14, 10:08 PM
Any door I've ever walked through, except maybe for a a specialized door like a turnstile, has been bidirectional.

Perhaps a better nomenclature would be "door connects" or "door joins".

I've never really understood the emphasis on "to" and "from" as it pertains to doors, unless you are trying to define the swing.

beegee
2005-01-14, 11:05 PM
I believe the default behaviour in Revit should be :-



the room the door is swinging inTO is the TO ROOM
and the room the door swing is away FROM is the FROM ROOM


That should update if the door is flipped.
It should also be able to be overwritten by the user, on particular cases.

LRaiz
2005-01-14, 11:38 PM
I believe the default behaviour in Revit should be :-


That should update if the door is flipped.
It should also be able to be overwritten by the user, on particular cases.

These requirements appear to be in conflict. If user overrides From and To by modifying door properties then what should be happening when user later flips the door swing?

If flipping the swing flips from/to then some users will be upset that their overrides are forgotten. OTOH if from and to stay put after door creation (as they do now) then other users are not happy. People also are not going to like an extra door property indicating presence or absence of an override

Damn if you do and damn if you don't.

beegee
2005-01-14, 11:50 PM
Damn if you do and damn if you don't.
Maybe so, and a good and valid point.

But I suggest that once a user chooses to over-ride the default, a warning dialogue box appears if the door is subsequently flipped, asking if the "from" & "to" need to be updated. In addition, an extra door property indicating an over-ride in place would be fine by me as well.

We have may unobtrusive and similar warning dialogs in place now, so I don't think one more will be a hardship.

Steve_Stafford
2005-01-15, 12:13 AM
I think the issue here is ownership of a door...a door belongs to a room and that's how many of us ultimately number a door. We can assume in many cases that a door swings into a room that it belongs to...until you deal with exiting or closets and such.

So ownership of the door is more important to me and From/To is a means to discerning ownership, a workaround if you will.

beegee
2005-01-15, 12:24 AM
So ownership of the door is more important to me and From/To is a means to discerning ownership, a workaround if you will.
Quite agree.

From / To provides an "automatic" means of determining ownership, which will be suitable in the vast majority of cases.
In the instances when it is not, the user needs the ability to over-write the default condition, and having done so, must be warned that an over-write exists if they wish to make any further change to that door's condition.

Sounds simple ( maybe not )

Steve_Stafford
2005-01-15, 12:27 AM
Sounds simple ( maybe not )Twereitwas...iddabeedun...

Doug
2005-01-15, 12:27 AM
What happened to the To & From fields in the door schedule setup?
Doug

LRaiz
2005-01-15, 12:56 AM
Maybe so, and a good and valid point.

But I suggest that once a user chooses to over-ride the default, a warning dialogue box appears if the door is subsequently flipped, asking if the "from" & "to" need to be updated. In addition, an extra door property indicating an over-ride in place would be fine by me as well.

We have may unobtrusive and similar warning dialogs in place now, so I don't think one more will be a hardship.
That may be a starting point of wishlist formulation.

beegee
2005-01-15, 03:11 AM
A Wishlist Poll has been posted HERE. (http://forums.augi.com/showthread.php?t=13302)