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.
No comments:
Post a Comment