Rooms vs. Spaces in Revit: Why Something So Simple Gets Complicated

In Revit, Architectural models use Rooms (blue), while Engineering models use Spaces (green). Rooms serve as placeholders for architectural information; Spaces host data needed by engineering systems. On paper, that sounds straightforward. In practice? It can get surprisingly messy—especially when all you want to do is tag the rooms… er, spaces.

Tagging 101

In an Architectural model, you tag Rooms with room tags to display the room name, number, and other properties.
When that architectural model is linked into an engineering model, engineers tag Spaces with space tags to show the same name and number information.

This creates the first big point of confusion:

Two different objects need to display the same name and number.
One comes from Architecture.
One comes from Engineering.
Both appear on drawings.
They need to match.

There are several ways to accomplish this—each with its own limitations.

---

Option 1: The Autodesk Space Naming Utility (SNU)

Autodesk provides the Space Naming Utility (SNU), which copies the Room Name and Room Number from the architecture’s Rooms into the engineer’s Spaces.

Simple, fast, reliable… mostly.

But SNU breaks down in edge cases.
For example, imagine a single large Room divided by Space Separation Lines. This creates multiple Spaces inside one Room. Each Space wants the same Room Name and Number—but Revit doesn’t allow duplicate Space Numbers.

So Revit appends a suffix like:

• Space 101

• Space 101-1

• Space 101-2

…and so on.

This can quickly become unmanageable, especially on large projects.

---

Option 2: Tag Spaces with the Room’s Information

Another approach is to customize the Space Tag so that it reads and displays the Room’s Name and Number instead of the Space’s own parameters.

This offers multiple advantages:

• Engineers can still store their engineering-specific Space properties (for tools like Trace or HAP).

• Tags stay visually consistent with architectural room names/numbers.

• No need to rely on SNU’s copying logic.

A related variation is tagging linked Rooms directly using a Room Tag in the engineering model. In some cases, this even eliminates the need to place Space objects entirely.

That said, I don’t recommend skipping Spaces, because the engineering benefits (flows, loads, calculations, schedules) overwhelmingly outweigh the few extra steps needed for setup.

---

The Phasing Curveball

Rooms and Spaces don’t behave like most Revit objects when phasing is involved.
They do not persist across phases.

If a room spans three phases with no physical change—existing, demo, new—you still need to:

• Create a separate Room in each phase

• Tag it in each phase

• Make sure the name/number stays identical manually

Then you must replicate that process for Spaces using whichever tagging strategy you adopted earlier.

And if one phase changes? You’re back to updating all copies, in both Rooms and Spaces.
This is one of Revit’s longer-standing headaches.

---

Linking, Interlinking, and the “Broken Room Bounding” Problem

On many real projects, architects send multiple Revit models:

• Interior & Exterior

• Shell & Core + Interior Fit-Out

• Separate discipline models

• Or various other combinations

Because these files come from outside the engineer’s network, their links arrive broken.

This is where things get risky.

If the links aren’t re-assembled correctly:

• Rooms may not form in the linked architectural model.

• Without Rooms, the MEP Spaces cannot detect their associated Rooms.

• Then SNU, room-tagging, and space-tagging strategies all fail.

• Engineering tags will show blank or incorrect data.

It snowballs fast.

Bottom line:
When an architectural model arrives from outside, all its links must be reconnected immediately.
Otherwise, Room/Space coordination is dead on arrival.

---

Closing Thoughts

Rooms and Spaces are foundational to coordination between architecture and engineering in Revit. But because they have different behaviors, don’t persist across phases, and depend heavily on correct linking, they can easily turn into a source of frustration.

With the right tagging strategy and disciplined file management, you can avoid most pitfalls—and ensure both models speak the same language.

It's been a wild ride. Now it's time to get back in business.

Working at CASE was an amazing experience. The collection of talent they brought together was unlike anything I’ve ever seen—truly next-level thinkers, builders, and innovators. I’ve always liked to drink from the fountain of knowledge, but that team was a fire hose. I’m grateful for every bit of guidance, inspiration, and camaraderie they offered.

Then came the buyout. One of CASE’s clients decided they wanted all that talent under their roof, and in many ways it made sense. But three years later, that once-in-a-lifetime team is now scattered to the four corners. I wish I could say we’ve all stayed tightly connected, but like so many things, the day-to-day hustle and distance took their toll.

In the decade since, I’ve been working as a Technology Manager for Consulting Engineers, supporting multidisciplinary teams, developing digital tools, and helping firms bridge the gap between design intent and practical implementation. It’s been a rewarding stretch—hands-on, fast-moving, and a front-row seat to how tech reshapes AEC workflows.

Now I’m circling back to some old interests. After far too long away from writing, it’s time to start again. I have a lot in the pipeline—thoughts, tools, and experiments I’m finally ready to share. I’m also deep into a new Revit Add-In that I’ll be unveiling soon.

If you’ve stuck around this long, thanks for being here. More to come.

Room Separation Lines Don't Play Well with Others

Please Use Sparingly

Room Separation lines are a necessary eval from an MEP perspective. There are times they must be used, and from an architectural perspective are completely appropriate.  Here is the rub, they don't just divide rooms, they also divide spaces. Spaces are used by MEP in place of rooms as they have more parameters pertinent to those trades.  The information derived from calculations performed either in Revit, or more commonly in external applications is stored in these space parameters. Now you may think if it should be two separate rooms, then we should treat them as two separate spaces right? Not necessarily.

The reading space above is separated from the lounge, stacks, and check-out spaces by room separation lines.  Unfortunately light from the windows in check-out and lounge will contribute to the lighting levels in reading.  Air being supplied to the stacks will flow into the reading space. But with room separation lines, there is no way to account for it.

When we are performing calculations for either lighting or HVAC, the two spaces communicate openly. The reason a room separation line was used in the first place is there is no physical separation. Light from one room will cross the imaginary separation line and impact the calculation for the adjacent room. The same is true for air and heat on the HVAC side.

Solutions for the MEP engineer are to use Zones as your export for analysis, which has other benefits as well. But if the doesn't make sense for the two spaces to be part of the same zone, then things get more complicated. There is no way from the MEP model to not have a room separation line from separating the spaces.  They must be deleted from the architectural model.  Then fake tags must be used to distinguish the two room tags from the architectural model, and they must be managed in the MEP model as well. Or the two rooms can be merged in most of the outside calculation platforms. If you are choosing to manage it outside Revit, you will have to be careful when updating to re-merge the spaces in your external software, and you will need to pick which of the original two spaces will be the container for the information.

Model It Right!

Another problem we see all too often with room separation lines is as a band-aid for poor model craft. Perhaps a room doesn't close properly due to an opening or non room bounding element that isn't obvious.  A room separation line is a quick way to fix the problem.  Unfortunately that gets translated in the calculation software as a wall opening. Assuming the line is drawn along the length of the exterior wall, then the room is seen as not having any surface separating it from the outside. To be brief, lots of calculations are reported wrong. 

Revit File Sizes

Revit’s approach of an all encompassing file can create some behemoth sized files.  How big you might ask, very big.  The file size you see on the disk is a compressed file format.  When that file is opened in active memory, the RAM used is about 20 times the file size.  You can check that using Windows Task Manager.  From the first submission (typically Design Development or DD’s) to 100% Construction Documents (CD’s) expect a growth factor of about 3 times the DD file size.  Let’s put some numbers on this… my office is currently working on a large project, about 300,000 Sqft.  The architectural and structural files that are each linked into the project represent the MEP model’s memory overhead.  Together these two files are measuring about 200 Megs.  Well, 200 Megs X 20 = 4 gigs of ram in use.  Then there are the MEP models that currently about 160 Megs x 20 = 3.2 gigs.  We are currently at our first submission, and are totaling 7.2 gigs of RAM being utilized.  By CD’s it will likely be about 7.2 x 3 = 21.6 gigs.  That is a lot of memory to have open at one time.  Does this mean you can’t open a Revit file if it requires more RAM than is installed in your computer?  Not at all.  It will do it’s best to open the file.  First it will fill up your available RAM, and then start cashing to your hard drive. That is when you watch the “busy” wheel in windows start grinding away at your profits.  There are some Strategies that will help manage the memory being used.

They include :

• Strip the models
• Workset management
• Family Files
• Hardware Helps
• Looking to the Future

Hosted or unhosted that is the question

When developing your content for MEP in particular, the choice to make content hosted or not can have some long term consequences.  Consider if your company will work in an environment with all content in one model, or if the architectural model will be linked in to your MEP model.  If you're working all in one model, then the wall hosted, and ceiling hosted objects may have some advantages.  If you're working with an architectural link, then you will likely want to consider unhosted families with the occasional surface hosted.

For one, with a link, there are no walls or ceilings, but all surfaces.  If you are working all in one model, then the ceiling hosted objects will cut the ceiling leaving voids for the ceiling grid. Another thing to always remember with MEP objects that are hosted in any way, if the object they are hosted to gets deleted, they become orphaned. At best they stay where they were, and occasionally they get lost out in left field.  More recent releases are better about not changing the positions of objects, but they can still get left behind.

Let's say the ceilings that lights are hosted to get deleted, and a new one created one foot higher, the lights will now be too low, the lighting calculations will be wrong, and the plenum space coordination is now shot.

So now let's consider the unhosted option workflow. During the design development phase, often the ceilings are not developed enough to safely host devices to, without knowing you will need to re-host them again later. There are many workaround to this for hosted content, all with some undesired side effects.  If your content is unhosted, it still needs a level reference, and you can set a height offset.  Later you can use excel to synchronize the space heights, and your light height offset values and get most of your lights in the right place at one time.

Syncing Data with Excel

There will still be some fine tuning for spaces with tray ceilings and such, but those should be specialty spaces that get more attention anyway.

I work @ CASE!

I am so excited to announce that I now work with the brilliant folks over at Case! I'm about to board a flight to NY to meet my new Co-workers. More on this to come in the near future. I think they just called my seat. 

I don't like Mark.

Here is my problem with Mark.  He marches to the beat of his own drum.  He continues to populate false and bogus information without any relevance or even context.  I'm referring to the property of Mark value in Revit.

What does "93" mean regarding this piece of pipe? Absolutely nothing.  It was automatically generated upon the pipe creation.  Some where, I must have set or reset the Mark value to some number, and it kept counting up to this pipe being number 93.  It is bad data that is constantly populated.  Well, why do I have a problem with this? While small in stature, little bits of data add up. Every element in the project has now several characters worth of bad data. And like pennies, they add up to dollars. Not to mention that too frequent occurrence of being populated with a strong of 50+ repeated characters.  Then when say a piping layout on the first floor is copied to the same place for the next ten floors, then Mark is hopelessly irrelevant. 

And should someone actually want to use Mark to indicate the particular unit name, then they have to delete bad information to make good information. And if they wanted to tag all elements using Mark Value can you trust the elements where it just kept counting. The property is bogus it may or may not be relevant it may or may not be accurate. So now someone has to go back and check all of them to see if they're correct or at least the ones that they want to be correct, not necessarily all of them. 

Yeah Mark is a no go for me. I say get rid of them. Don't use them! Create your own parameter for the values that you do want to schedule then you can clear out all the values of Mark with a clear conscience and actually reduce the file size some.

Rant over.