Showing posts with label Shared Coordinates. Show all posts
Showing posts with label Shared Coordinates. Show all posts

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

Wednesday, December 19, 2012

Shared Positioning

This is a topic that has – historically - caused confusion across all levels of Revit users, myself included. I seem to have to re-learn the ins and outs of shared coordinates and the myriad array of associated tools every time I have to intervene on a project where multiple linked models are employed. This week has been one of those weeks, but this time I am thoroughly documenting this topic in an effort to shorten the learning curve next time this comes up once again!

Flustered

For starters, HERE is a very good summary blog post by Steve Stafford with links to other of his posts on this very topic.

I will write more in detail on this as time permits, but in the meantime, I will offer the single most important strategy to avoid confusion: if you don’t need Shared Coordinates, don’t use them when linking and positioning models! Sounds simplistic, but it is valuable advice and you should ensure to touch on this in your BIM kick-off meeting. If you have separate discipline models for a particular building, they should link into each other with Auto – Origin to Origin from day one. This way you reserve Shared Coordinates for other purposes. Don’t use this system to fix sloppy and incorrect linking because you lose the flexibility to use it for other desirable purposes, such as reporting true site coordinates. For example if you want views showing Level 1 at 0’-0” in some sections/elevations, but want the ability to report the exact height above sea level or to report site building coordinates in a site plan, you won’t be able to do it simultaneously in the same project if you have consumed Shared Coordinates to fix improperly positioned models at project startup. EDIT: I should have worded this better. What I mean is that if you use Shared Coordinates as a linking fix with no regard to properly locating the shared coordinate origin and orientation based on a true survey mark, you would have to repeat the process later if you need to report coordinates relative to this point (especially the elevation above sea level), which can be a painful exercise later in the project.

The other problem I’m finding with the use of Shared Coordinates is that if a model with shared positioning is moved and this in turn causes Revit to save the location back to this linked model (sometimes even when nothing has actually moved), the Project Standards workset gets checked out and not properly relinquished. This results in a team member of one discipline (ex: Mechanical) owning the Project Standards workset in the Architectural model, which can lead to quite a bit of finger pointing! I’ve witnessed this several times when Architectural wants to edit the project address and they are locked out because Project Standards is owned by someone that has no business being in their file.

So are Shared Coordinates pure evil? I won’t dare go that far as their use might be absolutely necessary when exporting data to other applications, such as when needing IFCs for use in Solibri Model Checker. They are a great tool when used with care and caution, but they are undoubtedly one tough nut to crack.


Share/Save/Bookmark