Yes, if the entire building really needs to move away from the file's origin, the origin must stay the same.

Relocate Project is a slight of hand trick, try this example:

• Create a new empty project
• Open the Site plan View
• Make sure the PBP (Project Base Point-circle) and the SP (Survey Point-triangle) are visible
• Use Relocate Project, "move" it 1 meter to the left
• We'll find the SP is now 1 meter to the right, left behind marking where the origin was
• The SP identifies the origin of an alternate coordinate system, roughly equivalent to AutoCAD's WCS (World Coordinate System) origin
• The previous steps are essentially the same as moving the SP (clipped) to the right 1 meter instead (use Undo and try it)
• Using Relocate Project you see the PBP move but its really the SP that's changed, it just doesn't look like it because the PBP is reporting a different 0,0 coordinate offset now (more on that below).

In a sense Revit just shifted the world over, underneath our building, and the origin never really changed. If we try the steps above and make sure we can see elevation symbols it becomes more apparent when they don't change their relationship to the PBP after using Relocate Project. The PBP and SP start out at the same location in stock templates, but they are NOT marking the same information.

I believe it causes unnecessary confusion when we examine the PBP coordinate values (when selected) because it displays offset values relative to where the SP defines the WCS origin. It is even more confusing because we can move them both un-clipped which renders them annotation, to mark points of reference relative to their origin clipped locations.

In the situation described in OP, when we link in new files (using Auto-Origin to Origin) they don't see the origin (PBP) as being any different, they appear in the same place relative to the model and PBP. When we link in CAD files however, using Auto - by Shared Coordinates this forces Revit to import them based on the WCS which is now different. We'll find a new import will land in the old location, assuming we don't move the SP (clipped) away from where it was.

As an aside - Usually a building's position is derived from site conditions. Toward that end I believe it is helpful to establish a separate site model that holds survey file data (related civil/survey CAD files etc). This project uses Acquire Coordinates (or Specify Coordinates at Point) to define the Revit site's relationship to the civil/survey data.

The building model(s) can be created using a convenient Project North orientation. Then the building can be linked into the site model and positioned as required. Once satisfied the Publish Coordinates tool will "push" the necessary coordinate information to the building file so it will understand both its project relationship (file) and its real world site position and orientation.

If all models share this understanding then other CAD files that also use the same origin as their reference will import into Revit projects using Auto-by Shared Coordinates and land in the correct location too. A warning message does appear that the file(s) doesn't "share coordinates" so Revit will use the World Coordinate System of the file, which is the same as the other CAD files...so they line up.

A significant benefit of this approach is how flexible it will be when building models need to move. Move them in the site file and Publish Coordinates again to revise them. Revit will even generate a warning message that allows you to save the change immediately (click Save Now) or postpone saving (click OK) the changes until you are satisfied all repositioning is complete.

Thank you for that extensive reply. I had no idea how important the shared coordinate system is.

If linking with shared coordinates is so powerful, and linking by origin is so flawed, why even have link-by-origin as a feature in revit? I'm sure it's creating confusion for a lot of people.

Linking Auto-Origin to Origin isn't flawed, it works fine.

I'd say the flaw is that Revit hasn't done a good job of making Relocate Project easier to comprehend. It was initially intended to allow us to move a building up to a design elevation of 100 instead of 0 so there are no negative elevation values, perhaps more common in North American than elsewhere. We can use Relocate Project to move our project up to 100 but it doesn't really move at all. We change one parameter in our Level's type parameters (Elevation Base) and they all report elevations relative to 100 instead of 0, a sleight of hand trick and we get to see what we want without being concerned with actually modelling the building at an arbitrary higher elevation.

There isn't the same practical application of using it for lateral changes but the name implies that it could or should.

Shared Coordinates are the intended approach to allow us to define and manage our project's real world position, orientation and elevation; regardless of how well or poorly that is communicated by Revit's documentation.

Old thread, but perhaps there's an answer here to our dilemma. We usually link an AutoCAD column grid to our Revit file (origin to origin) so we can create our Revit model on the same coordinates as the AutoCAD plant drawings. A new user modeled a structure without doing this and his model is a few hundred feet North West of where the CAD column grid is. How can we move his model to match the AutoCAD Column grid? When I tried the above mentioned method, the column grid still gets imported (linked) into the wrong spot. I can move everything (objects) in a 3D view, then move everything else (grids and section lines, etc.) in a Plan view, but, obviously some things get disconnected in this process.

Where is the Revit model geometry in relation to the project base point, and the survey point? Are the PBP and SP both the same right now? Was the CAD column grid drawn a few hundred feet away from the origin point in AutoCAD originally?