Understanding SpatialElementFromToCalculationPoints – what are they even for?

[matthias.schmidt.sps]

tl;dr

SpatialElementFromToCalculationPoints seem to behave like a legacy feature whose original purpose has been lost.

1. Is there any actual practical benefit to using SpatialElementFromToCalculationPoints?

2. When these points are disabled, how does Revit determine FromRoom and ToRoom?

3. Is there any downside to turning off BuiltInParameter.ROOM_CALCULATION_POINT for all door families?

---

Long version

I'm trying to understand the real purpose and behavior of SpatialElementFromToCalculationPoints in door families. After digging through the API and running a number of tests, I’m not convinced they are very reliable - or even useful - in practice. I’d appreciate clarification from anyone who knows the intended design or internal algorithm.

---

1. Behavior when SpatialElementFromToCalculationPoints are disabled

If the calculation points are turned off in the family (so FamilyInstance.HasSpatialElementFromToCalculationPoints == false), Revit still assigns FromRoom and ToRoom.

With these points disabled:

• You can manually swap FromRoom and ToRoom in a schedule, without affecting the door swing.

• Or you can programmatically call FamilyInstance.FlipFromToRoom().

For comparison:
If calculation points are enabled and you swap them in a schedule, Revit will flip/mirror the family instance itself - without visual feedback, across dozens/hundreds of instances, even if the elements are pinned (!!!). This seems very risky and counterintuitive.

So far, disabled calculation points appear less dangerous and more flexible.

---

2. “More reliable” assignment? I'm not convinced

I’ve often seen the claim that SpatialElementFromToCalculationPoints provide "more reliable" room assignments because they tie the result to the door swing direction.

However, this only works if all of the following are true:

• the family was modeled "the right way"

• the calculation points were never flipped/rotated inside the family (but then: why would there even be a UI and API endpoint for doing so?)

• every version of every door family uses consistent conventions

• the points stay within valid room volumes in all situations

Given all the ways families are authored in real-world projects, this is not a safe assumption.

Also: the points are set for each family and cannot be overridden per-instance. If they could, they would be much more useful - a default behaviour would be defined in the Family, edge cases could be remedied for each FamilyInstance if needed. As-is I'd have to create copies of each Family for each edgecase - why no, thank you.

---

3. Sidenote: Odd default behavior and offsets

Opening default Revit door families:

• Their calculation point offsets seem arbitrary (2.325 ft [~708.6 mm] on one side of the wall, 1.675 ft [~510.7 mm] on the other side)

• Resetting them by toggling the parameter sets them to 1 ft on each side, symmetrical

• The default Z value is 0, which makes them highly susceptible to edge cases (sloped floors, raised thresholds, rooms with level offsets, double-height rooms, openings, etc.)

I cannot find any documentation that explains:

• why these distances were chosen

• why they differ between sides

• why Z=0 is used consistently

---

4. How are FromRoom / ToRoom computed when the points are disabled?

Tests suggest Revit uses a fallback logic that looks something like:

• a point offset 1.5 ft (~45.7 mm) normal to the host wall centerline

• at roughly half the door height (much more sensible than Z=0 to me)

This produces much more stable behavior in my tests compared to the hardcoded family points.

Can anyone confirm or deny that this is the built-in algorithm?
If so, why is it undocumented? Well, at least, I wasn't able to find documentation on this.
SpatialElementFromToCalculationPoints seem to behave like a legacy feature whose original purpose has been lost.

---

5. I’m considering removing calculation points from all door families

It appears safer and more flexible to simply disable the calculation points (BuiltInParameter.ROOM_CALCULATION_POINT = False):

• No unintended flipping of families through schedules.

• No dependency on poorly configured family geometry.

• More predictable and robust fallback room assignment.

Are there any real reasons not to do this?
Is there any modern workflow in which SpatialElementFromToCalculationPoints are necessary or beneficial?

---

Thanks in advance for any insights. Documentation or internal knowledge would be especially appreciated.

[GaryOrrMBI]

The Room Calculation point is the "out of date leftover". It was added to families so they could be scheduled according to the rooms that they were placed within They let you collect how many tables and chairs, or cabinets, or whatever other families that you want to track, by room. That point was adjustable so you could fine tune where it looked for it's containing room in relationship to the physical geometry of the family (recessed fire extinguisher cabinets within a wall might need a greater distance from the wall to ensure that it finds the correct room than a chair that can use it's origin point for example).

Doors and windows were then enhanced by adding the From Room / To Room as they allow for the passage of people, air, sunlight, etc from one side of a wall to another.

Those that had door and window families built to define that direction by the swing and/or facing (complicated controls to tie handing and the like to the physical swing or even different families with the handing and swing oriented differently) can still maintain that usage by keeping the Room Calculation Point enabled in their families (doing so ties the From Room / To Room to the physical placement of the family).

Disabling the Room Calculation Point removes that physical association and allows the From Room / To Room to become a data point that can be changed via a schedule and/or the flip FromRoomToRoom via the API). As far as the "preset" point locations/ distances... it's arbitrary and leftover from initial implementation. The real purpose is the direction from "side one" to "side two" as opposed to a singular point to define location. It can be flipped within the family to maintain coordination with any existing families in which the Room Calculation Point had been changed from the default "side", but the actual points have little to no meaning.

We have disabled the Room Calculation Point and use the From Room / To Room as a pure data parameter that we can manipulate for our own purposes (door number always gets changed to coordinate with the To Room and the To Room is always switched to the secure side , ie: the room that it serves, regardless of the swing/ handing for example).

-G