BIM Coordinates That Keep Terrain in Place in Revit

When imported terrain lands in the wrong place, the instinct is to grab it and move it until it lines up. It works for the afternoon. Then the survey is revised, the civil engineer links their model, or someone exports IFC, and the terrain is wrong again, by exactly the amount you moved it.

Terrain that stays in place comes from setting coordinates once, before the terrain arrives, and never moving the geometry by hand. This post goes through the four failures people actually hit with Revit terrain and the Autodesk tools that fix each one.

The three reference points Revit uses

Revit has three positions that matter for terrain:

Internal origin: fixed, never moves. All geometry is calculated from it.
Project base point: a convenient local zero for the building, used for dimensions and setting out.
Survey point: a known real-world position. Its coordinates define the model's shared coordinates.

Autodesk explains the relationship this way: "When you first create a model, the survey point and the project base point are located at the internal origin." Moving the survey point unclipped "moves the entire modeling work plane", while moving the project base point leaves the internal origin and work plane where they are (Autodesk, About the Maximum Distance Limit).

Terrain stays put when its numbers relate to these points in a way you have decided, not one you discover later.

Failure 1: the terrain lands kilometres away, or looks jagged

Cause: the CSV holds national-grid coordinates (hundreds of thousands of metres), so the points are far from Revit's internal origin.

Why it matters: Autodesk is explicit. "All geometry in a Revit model should be within 10 miles or 16 kilometers of the model's internal origin." The limit "applies to geometry created in Revit as well as incoming geometry from an import or a link", and beyond it "the graphical representation of elements becomes less reliable and less accurate" (Autodesk).

Fix: import terrain with coordinates relative to a local origin near the site, then tell Revit where that origin is in the real world through the survey point.

Pick a round origin near the site (for example easting 530000, northing 180000) and subtract it from every X and Y in the CSV. Topo-grapher's CSV already does this: X, Y, Z in metres relative to a UTM origin written in the file name.
Create the Toposolid: Massing & Site tab > Toposolid > Create from Import > Create from CSV, units in metres (Autodesk, Create a Toposolid from Imported Data).
Give that origin its real-world value with Manage tab > Coordinates > Specify Coordinates at a Point, picking the point that corresponds to your local 0,0 and entering the origin's easting and northing. To see where 0,0 is, turn on the internal origin in Visibility/Graphics (Site category). Test with one known point before relying on it, because where the CSV's 0,0 lands is easy to assume and worth confirming in your Revit version.

The geometry stays near the internal origin, and shared coordinates still report real-world values.

Failure 2: the Toposolid does not line up with the property lines

Cause: the property lines came from a survey DWG with its own coordinates, and the terrain came from a different source with different ones. Each is internally correct; they just do not share a reference.

Fix: make the survey the coordinate authority, then bring the terrain into that system.

Insert tab > Link CAD, choose the survey DWG, Positioning Auto - Center to Center.
Manage tab > Coordinates > Acquire Coordinates, click the link. Autodesk: "Revit aligns the survey point and the project base point with the geometric center of the link. The coordinates of the survey point and the project base point reflect the GIS coordinates from the link" (Autodesk, Link a DWG File and Acquire Its Coordinates).
Check the result: Manage tab > Project Location > Location should now show the GIS coordinate system, latitude and longitude from the DWG.
Make sure the terrain uses the same coordinate system as the survey. A terrain file in UTM will not match a survey in a national grid, even if both are "correct". Reproject one of them before import.

If the terrain is in the right system but still offset, check the vertical too: a survey in a local site datum (for example a benchmark set to 100.000 m) will not match terrain in national heights. See the vertical datum guide.

Failure 3: the terrain is mirrored or rotated

Mirrored almost always means swapped columns. Surveys often list Northing, Easting, Elevation (Y, X, Z). Revit expects X, Y, Z. Swap the first two columns and reimport.

Rotated usually means True North and Project North have been confused, or someone rotated the terrain to make a drawing look square. Rotate the view with Project North instead, and leave True North to the shared coordinates. When you acquire coordinates from a DWG, Autodesk notes the host model also takes True North from the link.

Failure 4: everything is 3.28 times too big, or too small

That is metres read as feet, or feet read as metres. Revit's CSV import asks for units in the Format dialog ("for example, decimal feet or meters"). Answer it deliberately. A terrain 1,000 times too large is millimetres read as metres.

Should you use shared coordinates or move the points?

Use shared coordinates. Moving the points (or the Toposolid) fixes one view and breaks every later exchange: the next survey revision, the civil link and the IFC export will all be offset by the amount you moved.

The one acceptable "move" is the one in Failure 1: subtracting a documented local origin before import, then recording that origin in the survey point. That is not moving the geometry; it is choosing where zero is, and writing it down.

If several consultant models are involved, decide which file is the coordinate authority and use Publish Coordinates from it only when the team agrees. Autodesk's help points to Publish Coordinates "if you need to push the geographic location to other models that are linked to this Revit model."

Generate a Toposolid-ready CSV free →

A coordinate check before every exchange

Before you issue a model with terrain:

Read the shared coordinates of two known points far apart on the site (a survey control point, a boundary corner) and compare them with the survey.
Check a spot elevation on the Toposolid against a known level.
Link the latest survey or civil model Auto - By Shared Coordinates and check it lands on the terrain.
Export a test IFC or DWG with shared coordinates and open it somewhere else.

Ten minutes here is cheaper than a contractor finding a 300 mm level error on site.

FAQ

Why doesn't my Toposolid from CSV line up with the property lines?
The CSV and the survey DWG use different coordinate systems or origins. Acquire coordinates from the survey, and make sure the CSV is in the same system and relative to a known point.

What is the best way to bring topography into Revit with shared coordinates?
Set shared coordinates first (Acquire Coordinates from the survey, or Specify Coordinates at a Point), then import terrain whose origin you know. Do not move the terrain afterwards.

How far from the origin can Revit terrain be?
Autodesk says all geometry should be within 10 miles or 16 km of the internal origin. Use a local origin for large-coordinate data.

Why is my terrain mirrored in Revit?
The file is probably Northing, Easting, Elevation. Revit reads columns as X, Y, Z, so swap the first two.

How do I get Toposolid point coordinates out of Revit?
Use Spot Coordinate annotations for individual points, or Dynamo to export vertices to CSV. Make sure you report shared coordinates, not internal ones.

Does Topo-grapher's CSV use real-world coordinates?
It uses metres relative to a UTM origin given in the file name. Enter that origin with Specify Coordinates at a Point to tie the model to the real world.