Rooms - differences between RB8.1 and RB9

[dbaldacchino]

Hi all,

In RB8.1, you could create "rooms" in schedules without placing them. These would show up as "Not Tagged". In RB9, you can also create rooms but they show up as "Not Placed".

In 8.1, when you tagged a space and later you decided to remove the tag, if that space was the only tagged one, Revit would ask you if you wanted to delete this space. If you chose not to, the space would show up "Not Tagged" in the schedule. Unfortunately in 9, this doesn't seem possible. Once you "place" a room, you cannot remove it without having it removed from the schedule. I don't like this at all and here's why. I like to start off my projects by inputting all the programmed spaces and format the schedule to match what the program layout is (sections, groupings, order, etc.). Then we have a schedule that shows untagged spaces early in SD/DD so we can tell if we missed significant spaces. If a space gets deleted from the original program (or two spaces combined into one), we would remove the tag from the plan views, but would not delete the space in order to keep track of the changes (space shows as untagged). With the new Room object, we cannot do this anymore as once you place a room, there's no way to "unplace" it.

I don't know if anyone has figured a way to do this or if anyone is using Revit in a similar way and found this to be a problem (inputting the program into a schedule in the beginning of a project). Your feedback is greatly appreciated!

[cphubb]

David,

I think you are right about the new behavior. We usually have the written program on our desk and input that as actual rooms. We then use the schedule for QA and to find and delete any rooms that are untagged and therefore invisible. I think you will need to modify how you do the rooms but the added usability of the rooms (Phasing visibility tag in section etc) outweigh that in my opinion. We almost always use the schedules on the backend after objects are created.

[dbaldacchino]

Thanks Chris.

We found it very useful to start by inputting the program first. Then as we drew the spaces, we tagged from the already inputted spaces by selecting the space from the drop-down, thus eliminating the check we typically have to go through to make sure we nailed every space. This might seem trivial, but it's quite useful in large programs.

What I'm doing at the moment is to move the room object out of the building and place it on a special workset. That way the "Program" schedule shows "Not Enclosed" instead, but it's still there. This is useful to us to keep track of changes in one place. As Phil Read says, BIM-->Building Information Management :)
I'm in no way saying I don't like the room object, far from that. I do have a problem with tags not following rooms as door tags do with doors, but maybe someday we'll get that functionality. I just wish that we had the option to "unplace" a room, or have Revit ask if we want to really delete the room just like it did in 8.1. I know people get annoyed with the warnings dialog, but this is one instance where I'd like Revit to give me an option.

[Steve_Stafford]

Good catch David. This seems to be clearly contrary to intent and definitely different from past workflow. The rooms should not be deleted from the schedule if you delete them so you can place them again, not have to recreate the room and all the data associated with it.

Will you contact support to let them know? (I just did...)

In the meantime, you can move a room by selecting it and its tag and (or move) to a new location. Any tags in other views will cause Revit to bark at you about being outside their boundary but you can fix them.

If you need to move them to another level and are prepared to locate them immediately you can cut/paste them to the other level. Technically you can paste them anywhere if their walls aren't there yet.

[dbaldacchino]

Thanks Steve. Yes I'm going to file a SR for this and also elaborate on the tags not following rooms when moved. I mentioned this during Beta too and the immediate solution would have been to have the leader turn on when a room moves (I don't like this, but it's slightly better than the current functionality).

In my current project, I decided to have tags deleted when there were swift changes happening to rooms (in all other views other than the one I'm working on), and then I'd go back and paste the tags back in each view...it's an unnecessary maintenance chore. Not to mention that other users were not understanding what was going on with the various error messages and I'd end up with deleted rooms and redundant spaces (tags moved in one view but not the others). With the room object, we're closer to putting this issue to rest.

[sbrown]

Thank you for posting this, I haven't started a new job yet in R9 and this is a huge issue for us as I go to great trouble now ,and sold management on the fact that we should do our programs in Revit instead of excel, so we can keep more accurate area comparisons. So we create the rooms assign them to categories and subcategories, set up program area and calculated values to compare the program value to the actual. Hopefully this will get fixed asap.

[dbaldacchino]

Sounds very similar to what we've been doing. Our program is still done in Excel and I doubt that'll change. This is one of the reasons that one of my top wishes is the capability to import directly from an Excel spreadhsheet.

I'm using a room parameter "In Program" (yes/no) so I can keep track of spaces that get added outside of the program. Circulation spaces are typical of this (they're in the program as a factor and not as individual spaces). We want to get more analytical data out of a finished project and the way to do it is to input as much info. as possible and keep track of program changes.

[Steve_Stafford]

...This is one of the reasons that one of my top wishes is the capability to import directly from an Excel spreadhsheet...I know a guy who is working on something using the API so you might get your wish granted sooner than later? :wink: