Skip to content
RevitBootcamp2027 edition
Core model4 min readTeam fluencyModeling

Coordinates and positioning

Internal Origin, Project Base Point, Survey Point, shared coordinates, true north vs. project north — and the failures each one causes.

Coordinate mistakes are the most expensive class of Revit error, because they're invisible until five disciplines try to assemble a federated model and nothing lines up. This page is short and worth knowing cold.

The three points

Internal Origin

Revit's true 0,0,0. It is invisible by default, cannot be moved, and is what "Origin to Origin" link positioning refers to.

Keep all model geometry reasonably close to it. Autodesk's guidance is within about 10 miles (16 km), with 20 miles as the point where things break. Beyond that you get:

  • Visible geometric inaccuracy from floating-point precision loss
  • Views that behave erratically, especially sections and elevations
  • Export problems and unpredictable rounding

Models placed at real-world survey coordinates (e.g. state plane, with values in the millions of feet) are the usual cause. Don't do that — use shared coordinates instead.

To see it: VV → Model Categories → Site → Internal Origin (Revit 2020.2+).

Project Base Point (PBP)

The project's local reference — typically a building corner or the intersection of grids A-1. This is what your drawings dimension from and what spot coordinates report against by default.

Moving it changes reported coordinates without moving geometry, if you move it unclipped. Which brings us to the clip.

Survey Point (SP)

The real-world surveyed reference: actual site coordinates (N/E or lat/long derived) and elevation above datum.

The clip

Both PBP and SP display a paperclip icon. It changes what dragging does:

State Dragging the point
Clipped (clip closed) Moves the whole coordinate system — the model appears to move relative to the world
Unclipped (clip open) Moves just the marker — you're re-declaring where the reference is

Nine times out of ten you want it unclipped: you're telling Revit "the survey reference is at this corner", not moving the building.

Right-click either point → Move to Startup Location resets it.

Shared coordinates

The mechanism that makes multiple files agree on real-world position.

One model is the coordinate authority — usually the architectural model, or a dedicated site/shell model. Then:

  • Acquire Coordinates (Manage → Coordinates → Acquire Coordinates, pick a link) — your model adopts the linked model's coordinate system.
  • Publish Coordinates (pick a link) — you push your coordinate system into the linked file. This writes to the other file, so it will ask to save it, and on a workshared link it needs to be available.

Once shared, link with Positioning: Auto – By Shared Coordinates and everything lands correctly.

Do this once, early, and write down in the BEP who owns coordinates. Retrofitting shared coordinates onto a project with six linked models mid-way is a genuinely bad week.

When inserting a link, the Positioning dropdown decides everything:

Option Use when
Auto – Origin to Origin Both models were set up from the same template near the origin. The common default and usually correct early on.
Auto – By Shared Coordinates Coordinates have been published/acquired. Correct on a real project.
Auto – Center to Center Almost never. It aligns bounding-box centres, which changes as either model changes.
Manual – Origin / Base Point / Center You place it by hand. Fine for a one-off reference, wrong for coordination.

If a link comes in a mile away or rotated, the answer is to fix the coordinate agreement — not to drag it until it looks right. Dragging it breaks the agreement silently for everyone else.

True North vs. Project North

Two rotations, and confusing them produces drawings with north arrows that lie.

  • Project North is the orientation you draw in — usually the building squared up to the page.
  • True North is actual geographic north.

Set the relationship once: in a plan view, set the view's Orientation property to True North, then Manage → Position → Rotate True North and rotate. The building doesn't move; the coordinate system does.

Then individual views choose which orientation to display via that same Orientation property. Your site plan shows True North; your floor plans show Project North.

Never rotate the building itself to achieve this. You'll break grid alignment with every other discipline.

Elevation: three heights for one floor

A level's Elevation is relative to the internal origin. But a project usually needs to report height above a survey datum too, and the numbers differ.

  • Manage → Project Base Point has an Elev field — the PBP's height.
  • The Survey Point's Elev is the real-world datum height.
  • A level's Elevation Base parameter (Project Base Point or Survey Point) chooses which one level tags report against.

So a level can legitimately read +12'-0" on one tag and +124'-6" on another, and both are correct. Check Elevation Base before you decide a tag is wrong.

Spot coordinates and spot elevations

Annotate → Spot Coordinate / Spot Elevation place annotation reporting a point's position. Their type parameters choose whether they report relative to the Project Base Point or the Survey Point — which is exactly the ambiguity above, made visible on a drawing. Set it deliberately.

Symptoms → causes

Symptom Cause
Link is far away / rotated Wrong positioning option, or coordinates never shared
Geometry looks slightly off, sections misbehave Model too far from Internal Origin
Level tags disagree between drawings Different Elevation Base settings
North arrow points the wrong way View Orientation, or True North never set
Coordinates changed after someone "fixed" the base point PBP dragged while clipped
Two disciplines' grids offset by a consistent amount Copy/Monitor never set up, or one model moved

Go deeper