Thursday, June 27, 2013

Positioning of Linked Models – Part 1

NOTE: This is a re-post from the HOK BIM Solutions blog

Much has been said about this topic and it continues to be a source of confusion for users of all levels.

When linking models, unless Shared Coordinates have been properly set up between them all, you cannot position them using this method. It seems to be a common myth that linking models by shared coordinates will “just work” and they will land where expected. Think about it: if you never told Revit how various models relate to each other (distance and rotation), how is the software supposed to just know?

First off, let’s get the terminology straight and lay out some facts.

Fact #1

Every CAD software uses Cartesian Coordinates to locate objects in digital space. You start with a fixed Origin (0,0,0) and three Axes (X,Y & Z). In traditional 2D CAD packages, the Origin and Axes are exposed to the user through visual means, whilst in Revit they are not as “in your face”, but make no mistake: they are still there! This fixed system is essential to position elements in space such as points, lines, planes, surfaces and solids.

Startup LocationTo find the fixed Origin in a Revit project, you can either use the older, harder way (link a CAD file that contains some linework drawn at 0,0,0 with Auto – Origin to Origin) or the easier, newer way: Use an unclipped Project Base Point and pick Move to Startup Location in the right-click context menu.

PBP

Just in case you forgot how to turn this on, see the image on the left (V/G dialog; make sure at least Architecture is selected in the filter list).

NOTE: In AutoCad, the fixed Origin and Axes are called the World Coordinate System. In Revit we refer to them as the Project Internal Coordinate System.

Fact #2

When you link with the Auto – Origin to Origin option, the Project Internal Coordinate System of the linked models will be aligned to that of the host model. So if at project startup reference models were linked haphazardly (ex: with Auto – Center to Center or arbitrarily shifted around after linking), you are guaranteed to end up with incorrectly positioned models. To circumvent this problem, we can set up Shared Coordinates in each model, share them through “acquiring” or “publishing” tools, and then link with this option. Note that a successful outcome doesn’t happen auto-magically on its own!

Fact #3

In most CAD software, you will find the concept of a User Coordinate System (UCS), which is another Cartesian Coordinate System similar to the World Coordinate System (WCS). A user can define any number of named UCSs and these are positioned in space relative to the WCS. Now you can probably understand why the WCS is fixed since you must have an anchor point in 3D space for relative positioning to work.

When we talk about Shared Coordinates in Revit, we are talking about their equivalent counterpart in 2D CAD: User Coordinate systems. We can define multiple named systems in the Site tab of the Location Weather and Site dialog. Named Shared Coordinate systems (Sites) are located relative to the Project Internal Coordinate System. In Plan views, Project North is defined by the Y-axis of the Project Internal Coordinate System, while True North is defined by the Y-axis of the Shared Coordinate System (the named “Site” per the dialog below):

Sites

When you link with the Auto – By Shared Coordinates option, the Shared Coordinate system of the linked models (for the current named “Site”) will be aligned to the Shared Coordinate system of the current named “Site” in the host model, given that Shared Coordinates have been properly set up between models. If you try to link models that have yet to be synchronized (by publishing or acquiring Shared Coordinates), Revit will not allow you to use this option:

Coordinates not Shared

Revit has always strived to describe functionality using terms that are familiar to the building industry, but I think that the ones used while manipulating coordinate systems do not work well for most common model linking scenarios. Since terminology is so different from that used in generic CAD programs, it makes things harder to visualize and understand sometimes, especially for users that started in 2D CAD. The main problem with named UCSs in Revit being called “Sites” is that if a consultant is linking parts of a building to parts of the same or another building, they probably do not think of “Sites” for this exercise!

The primary reason for the current implementation is to give us the ability to place multiple instances of the same building around a site (ex: the same home floor plan peppered around a housing development). For most typical project workflows, we just need one “site” definition for the purpose of locating links in 3D space and usually don’t even bother changing the stock site name “Internal” to something else.

In Part 2 of this post, we will look in more detail at some of the most common linking scenarios and discuss strategies to set up Shared Coordinates and linking Best Practices.


Share/Save/Bookmark

5 comments:

Alfredo Medina said...

This is going to be a very interesting series. Can't wait for post # 2. Thanks David for sharing this important information. Any new explanation of this topic is welcome, since it is a common cause for a headache. I remember the picture you posted in a previous post, about a guy grabbing his head in front of the computer because of the misplaced linked models. We don't want to be like him!

Dave Baldacchino said...

You're welcome! I noticed it was starting to get lengthy and there's really not much you can do to thoroughly explain in detail, so I thought of splitting in at least two, perhaps more parts.

Alfredo Medina said...

One good reference, which helped me understand this topic, is the handout of a lab at AU by Derek Renn, entitled "Revit MEP Survival Kit". Users who are under subscription can find the handout in the AU website. There are more good documents, of course. This just happens to be a class that I attended, and I thought the instructor did a very good job at explaining this topic.

tmarq29 said...

This is a very timely post. I am working with a model in which we thought we set up shared coordinates prior to starting our efforts, however, it recently became clear this was not the case. Lanscape and civil, who are both working in CAD, are using real work coordinates, and we set our revit model up around 0,0,0, or so we thought.

I currently show an Internal Survey Point at 0,0,0, and a Project Base Point at 0,0,465. I think that I need to adjust my internal survey point to match the coordinates povided by the civil engineer and put the project base point at 0,0,0. Is that correct?

Dave Baldacchino said...

The answer (as usual) is...it depends! What is your desirable end result? If you want to report true coordinates based on the survey, then you need to set your shared coordinate origin on the known benchmark/survey mark shown on the linked CAD survey. The easiest and most straight-forward way of achieving this is via Manage tab>Coordinates on the Project Location panel>Specify Coordinates at Point. If reporting true site coordinates is not important, then your shared coordinate origin can be anywhere you want, as long as it is in the same relative position in all your models.

From what you explained, I cannot tell whether the Survey Point (the Shared Coordinate system origin) has been moved as it always says "0,0,0" unless it was moved in an unclipped state. To tell if it is still aligned to the Project internal 0,0,0, unclip the Project Basepoint and select the option to Move to Startup. If the Project Basepoint stay aligned with the Survey Point, then everything is still at the Project Internal origin. In this case you have set your "Z" (elevation) of your Project basepoint to 465', so probably your first level is reporting this value. Typically you want Levels reporting based on the Survey Point to report true elevation above sea level and Levels reporting based on the Project Basepoint to start at some logical elevation, such as 0'-0".

Post a Comment