20 Mile Threshold on Import

This is a follow up to my earlier post this week regarding the 20 mile threshold. A comment to that post mentioned that the governing extent is equivalent to a 10 mile radius sphere whose origin is at 0,0,0. In my own testing I've observed the threshold is more closely defined as a cube.

This image is a 10 mile radius sphere with a line segment that travels beyond the edges of the sphere but within the boundary that a cube would have.

You can see the highlighted square is the extent of the DWG file and line extends outside of the sphere at each end but is still inside the boundary of where a cube would lie instead.

This image is the same file but the line is altered to extend beyond the edge of the sphere/cube extent.

This is the message that appears when I reloaded the file after altering the line's extent.

The warning can be avoided if we ensure that the DWG file doesn't have any elements that extend beyond the 20 mile cube (10 mile radius). The cube can be quite far from the origin of the DWG file but nothing can be outside the cube's boundary.

Active View can Matter When Linking Using Positioning Auto - Center to Center

If you link a model via Positioning: Auto - Center to Center in a plan view its zero elevation will align with the host model's zero elevation.

Do that in an elevation or section view however and the linked model may not rest at the correct Zero elevation. The discrepancy man be very subtle or quite obvious. It will depend on the adjusted extents of the view that is active.

The trigger appears to be the elevation or section view being cropped very shallow (only one level visible) prior to linking the model (tested as far back as Revit 2015). If all the levels are visible in the view it seems to be more reliable.

Far safer me thinks to just link via a plan view, something to watch out for. 

Revit 2016 R2 - Positioning by Auto - Project Base Point to Project Base Point

This is an interesting development for reconciling the misalignment of models. This gives us the option of linking a RVT model according to the location of its Project Base Point (PBP) and aligning it with our own.

Let's imagine a scenario where our structural engineer decides to mock-up a preliminary model but does so without the benefit of having the architectural model linked in yet. This new feature allows the engineer to either move the PBP un-clipped (see warning below) to an agreed upon grid intersection or to start by placing their grids at the default PBP location in their model.

All I have to do to get their model to align with my model properly now is make sure I move my PBP un-clipped (again see warning below) to our equivalent grid location or be grateful I was lucky to have guessed that we'd start our grids at the same location to start with. If I didn't guess correctly then moving it un-clipped puts it in the correct location and the link lines up nicely.

Being able to move the PBP un-clipped is helpful for Revit to Revit alignment. It DOES NOT address exporting to DWG however (nor appending to Navisworks). If each model is exported using Coordinate System Basis: Project Internal they will not line up with one another because the model's file origin is not altered. If each trade is careful to start modeling the agreed upon grid intersection at their templates's default PBP location (not moved at all) then they'll line up when their exported files are opened in AutoCAD or Navisworks.

I'm not sure we can rely on that if we can't count on them waiting for our model to use as a linked reference first? Still it is an interesting development. Hopefully it doesn't just contribute to the existing confusion regarding linked RVT file positioning.

My recommendations?

• Make sure all trades agree to begin their work referencing their own PBP with the same understanding. For example, agree in advance that the bottom left grid intersection shall occur at the PBP location (like shown in my images). This will ensure that exported data will have the same file origin.
• Don't move the PBP un-clipped to reconcile the PBP location IF you want to be able to export using Project Internal.
• Only move the PBP un-clipped if you will rely on Shared Coordinates to deal with external model alignment in other applications.

Link Positioning Manual - Base Point

AutoCAD has a feature called Base which allows us to specify an alternate insertion point that will be referenced (instead of the origin) when that file is inserted into another DWG file, either as an external reference or a block. Revit has a positioning option called Manual - Base Point. Sounds good except it doesn't work.

I created a DWG file (AutoCAD 2016) and sketched two squares, one at the actual origin and another one elsewhere. I used Base to reassign the insertion point to the bottom left corner of the other square, the one that isn't actually at the origin.

This is what I see when I use the Manual - Base Point option.

Help still says...

Short story...sounds good but doesn't work.

Acquiring Coordinates between Trades

Revit's shared coordinate features routinely confuse people. I believe I understand them well but I find the various ways people manage to use them can be quite confusing. I've written about this feature quite a bit, enough that I've created a summary of related posts. I was reading a thread at RFO where a user was describing an error message about Shared Sites.

That message appears when a shared coordinate relationship exists between two files and the linked file involved is moved. The thread at RFO hasn't shared a resolution because the person who wrote the original post hasn't replied to my last round of questions. Their claim is that the situation I've described isn't involved. Without more evidence it's hard to say what is causing their situation.

The point of this post is that they also described how they used Shared Coordinates to adjust the position of their work compared to the other team's project file. I've found with some experimentation of my own that it is effective until (IF) the source file alters its own shared coordinate relationship. If that occurs then its necessary to start over, first using the reset technique listed later in this post and then repeating these steps.

Keep in mind, this approach works if you begin modeling your work before you receive a model to use as a reference. Ideally this wouldn't happen but apparently it does. When you do receive another model it's very likely that it won't align with your work. Take these steps to reconcile the misalignment:

• Insert ribbon > Link Revit > select a Revit Model
• Positioning: Auto - Origin to Origin
• Move their model into alignment with ours
• Manage ribbon > Coordinates > Acquire Coordinates - select their linked model
• Delete their linked model (yes, it's counter-intuitive)
• Insert ribbon > Link Revit > select their model again (this time it IS sharing coordinates)
• Positioning: by Shared Coordinates
• Save your work

Our model should now be in sync with theirs until (IF) they alter their shared coordinates. We are using the Shared Coordinates feature to share a common understanding of respective project's shared coordinate origin.

For some background information, Revit projects have a file (reference) origin that does not change, in a way it's like AutoCAD's World Coordinate System (WCS). The shared coordinate concept we are using is similar to using the User Coordinate System (UCS) in AutoCAD to provide an alternate way of seeing the model.

If the team whose model we used to acquire coordinates from revise their shared coordinates in the future we'll have to repeat the process. To do that we'll have to reset the shared coordinates first. We'll also be able to avoid generating the Shared Sites error message above. Revit stores information in our project file about a linked file that it uses to know if a project is sharing coordinates with it or not and we have to break that relationship to reset shared coordinates. This technique uses a separate temporary project file to acquire coordinates from instead. A file can only acquire and share coordinates based on one source file at a time.

We can follow these steps to reset shared coordinates:

• Create a new blank project file
• Put a pair of crossing grids in plan so we can see it when it is linked later.
• Save the project
• Close the project
• Open our model
• Delete the existing linked model (click Remove Link in the warning that appears)
• Insert ribbon > Link Revit > select our temporary new blank project
• Positioning: Auto - Origin to Origin
• Manage ribbon > Coordinates > Acquire Coordinates > select the blank project we imported
• Save our project - it now thinks it is in sync with this new project instead.
• Delete the linked project (Remove Link)
• Save our project - Coordinates are still reset, we can link the real model and acquire coordinates again

Ideally when we link models together we should start with Auto - Origin to Origin because that's all they have as a common reference. Projects usually start with the architect and they establish the coordinate relationship with the site and survey data. Using Auto - Origin to Origin works if at the outset we agree that somebody establishes the site survey relationship and the rest of us all use their model to define our relationship to theirs.

The technique I've describe is using Shared Coordinates to align models instead of using it to align it to the site/survey data. This means that our models will align but exporting to DWG using Shared Coordinates won't necessarily align with the survey data. If this relationship is established after we've aligned our models with this method it is necessary to reset and repeat the process described above to allow our model to acquire the new coordinate relationship.

It's been my observation that Revit's Acquire Coordinates tool does not work well on projects that have VERY large coordinate values (based on survey data). When I write "does not work well" I mean Revit fails to acquire the correct coordinate values. When this occurs I've found that the coordinate values I expected to see were off roughly (less than they should be) by a factor of 10 or 100. In contrast, Revit's Specify Coordinates at Point (SCaP) tool always works when Acquire Coordinates doesn't. It does not define a shared coordinate relationship however. Using SCaP defines what the shared coordinates are at a specific location in the model but it does not store a "relationship" to another file like using Acquire Coordinates does.

I've described one approach to dealing with multi-model multi-discipline sharing of coordinate data HERE. The process described by that post is far more comprehensive and is meant to deal with the entire team. This post is meant to help resolve the relationship between one trade and another. As soon as everyone else gets involved it is important to have one team establish the single source coordinate system to use. A Revit project file can only share a coordinate relationship with one other source file.