Project Base Point Manipulation

I written before that I occasionally experience something that feels like a "Revitary alignment" regarding features in Revit. I'll see a post at AUGI or get an email or two from friends or clients asking about the same thing or theme. I recently ran into a user that manipulated their project by moving the Project Base Point. Then a post at AUGi meandered into a related conversation.

General Statements

• The Survey Point allows us to show where an imported CAD file's origin is relative to your model (CLIPPED)
• The Survey Point allows us to identify a benchmark location on the site instead of referencing source file's origin (UNCLIPPED)
• The Project Base Point does not ever "need" to be moved (CLIPPED) normally (my opinion/belief/preference)
• The Project Base Point will allow us to move our project on the site to reposition it (CLIPPED) but the file origin isn't changed
• The Project Base Point (UNCLIPPED) will let us identify an alternate location that Spot Elevations and Spot Coordinates can reference

Applied to a Project

Let's say you design a house, import a survey and it's off to the right and above your building. If you use Acquire Coordinates on the survey file you should find the Survey Point (CLIPPED) moves to mark the origin of the source survey data file (sometimes this is quite far away). The Project Base Point (CLIPPED) can be used to reposition the building over the site. Just drag or move it with specific values. What you see moving is the "Project". The file origin is untouched and you should see that the linked survey file isn't moving either. If you import a small origin "marker" file using Auto - Origin to Origin you'll find that it lands at the Project Base Point. Now if you move the Project Base Point (UNCLIPPED) you see that you can move the icon to another location but it still references the "file origin" (see image).

That approach works for a single building on site but is not very effective for multiple buildings on site. The approach I advocate where we create a site file that is coordinated with survey data and serves as the master coordinator for multiple buildings which are linked into this master site file is much more effective and versatile. Since this subject can be confusing enough I advocate using the same approach for any project so I can learn one technique and use it over and over, since it works for any project.

Transfer Project Standards and Shared Coordinates

These two are not friends. They are even less friendly when worksets are involved. In earlier releases the project base point and survey point were assigned to Workset1 (2012 and older). In a post some time ago I mentioned a support issue that IDEATE's techs encountered where a user assigned them to a different workset and eventually deleted that workst. It resulted in unpleasant crashing.

If you look closely in 2013 and 2014 you'll find they are assigned to a workset called Project Info and we can't change that anymore.

Unfortunately the more mundane information like the project name, number, issue date, client name and address and many more are also Project Info.

When we use Transfer Project Standards hoping to share the same mundane project info with related linked project files (seems a reasonable expectation) Revit wants to transfer project base point and survey point information too. You'll get this dialog when you fire up Transfer Project Standards (TPS).

This is what my dummy project looks like before using TPS, note the Survey Point's coordinate values and position.

Here's what it looks like after TPS is done. The project base point and survey point have reversed their orientation to one another and they are very far apart now (I zoomed in closer though), far enough that the walls are tiny and hiding under the project base point icon.

If two files are already sharing coordinates they aren't immune to this "feature" either. In my testing I find that the coordinates still get messed up if I use Transfer Project Standards and Overwrite in order to pass along the other project information. It appears that the safest thing to do once Shared Coordinates are established is... DON'T Transfer Project Standards AND leave Project Info selected.

I think that the Project Base Point and Survey Point should be more isolated so they have their own Project Setting based workset, not shared with other Project Info. I'm glad they made it harder (impossible) to reassign them to a different workset to eliminate the other problem I mentioned earlier but they've introduced a new quirk as a result.

I find it mildly amusing that Transfer Project Standards acronym is TPS...reports anyone?

Lock Down Shared Coordinate Relationships

The more complicated a project is the more trouble someone casually (accidentally) moving a building file can create. The simplest solution is to pin a linked model to interfere with accidental movement. Moving a pinned link takes a deliberate action.

We can put another speed bump in the road by using Worksets as a security guard to make it harder to move a linked file. Assign each link to its own workset and then create a new username like "Link Admin" and while working as this user make each link's workset editable (take ownership of each link's workset). When you synchronize (SwC) don't relinquish those worksets. Next time someone accidentally drags a linked file they'll be warned that "Link Admin says no".

One more step you can take which also involves worksets is to make the Project Info workset editable too, for each building file. The Project Info workset is located in the Project Standards group.

Taking this approach prevents shared coordinates from being altered inadvertently or otherwise. Same strategy, same user, same refusal to relinquish the worksets this user borrowed. This needs to be done in all the linked models as well as a master site model if used to establish the shared coordinates.

DWG Files and Funky Snapping

Importing survey files has always been problematic with Revit. Two things are fundamental issues: large file extents and distance from origin.

Geometry that is far apart will annoy Revit, geometry more than 20 miles in extents is the current "line in the sand". Just how precise this 20 mile consideration is a little hard to pin down. There must be some specific logic or algorithm the application uses but I've tried numerous times without success to arrive at something consistently true.

For example I've tried to draw squares and cubes, even circles and spheres to test the extremes and predict the trigger of the error messages I've written about before. As soon as I think I have something I can predict I try it again and get a slightly different result. My general rule of thumb is to try hard to make sure that I don't have extents that exceed a sphere that is 20 miles in diameter.

The other issue is when the data in the CAD file is small enough in extents but really far away from the file's origin, according to the WCS which is all Revit really pays any attention to. I can have a relatively small project site survey but far from origin and end up with Revit using Auto - Center to Center to place it. That's not really a problem though. We can just tell Revit how to resolve that with the Specify Coordinates at Point tool.

Now as for the title of this post, Revit hollers when our file is "too big". The warning tells us that this situation may affect the graphic depiction of information on screen.

This manifests itself in snap icons that appear to miss the element we are attempting to reference in the CAD file. It also shows up when you use the Pick tool to place lines and the sensitivity of the tool seems offset somewhat from where we see the line.

With Revit 2013 they've added an option in the Import dialog that says "Correct lines that are slightly off axis". This is a bit of spin unfortunately because this addition means it acknowledges that Revit has been altering them before, all along. Part of the solution to the funky snapping is resolved with 2013, don't check this option.

With Revit 2012 we can still avoid it but we have to import the DWG files a little differently. The trick is to let Revit place them using Auto - Center to Center and then move files, however many you need to use, into place manually. If we try to use the trick to Specify Coordinates using one file first and then import the rest using "Auto - by Shared Coordinates" it will trigger something internally that in turn triggers the snapping issue. That trick generates a message that these files aren't sharing coordinates but the end result is that they land in the correct location because shared coordinates are matching their own understanding of the WCS.

Here's a summary of steps, sort of...

Examine your survey file and make sure it isn't too large.

If it is you need to reduce it so just the really relevant part of the site is what you import. I realize that there may be situations that challenge this assumption but if you create two files from one that provides two that are small enough to avoid the error message about extents then you can still bring them in, position them manually and then specific coordinates.

Once you've resolved the survey file checking, pick a spot in each file that can be used as a common reference benchmark. You'll need it to move them into position in Revit. Write down what the coordinates are for this benchmark.

Now you can import the files into Revit. Use the Auto - Center to Center option. In Revit 2013 don't check the "Correct lines" option. You don't have this option in 2012 but this process will still work.

Move the files into position keeping them all near the Revit project file origin. Now you can use the Specify Coordinates at Point (SCaP) tool to match up Revit with your benchmark in the cad file. Unclip the Survey Point and move it to the benchmark location. Fire up the SCaP tool and enter the matching coordinate values.

Revit now understands your real world situation. You should find that snapping to the imported file elements is not showing the graphical glitch.

Important, there is one more thing to avoid, don't create a master survey file that uses attached Xref's to combine several files together into a single file that gets imported into Revit. Doing this will trigger the snapping issue again. It does it in 2012 and 2013 regardless. I believe that the Xref's mark the origin somehow in the master file which creates an unavoidable file extents problem which brings the snapping issue back to life.

Easy?? Wish it were easier!

BIM Coordinator for Civil 3D and Revit

Autodesk Labs posted an application that was developed by Autodesk Consulting. You can read more information HERE.

It functions as a plug-in that is installed in both applications, Civil 3D and Revit. It allows a Civil 3D user to define the shared coordinate system to be passed on to a Revit project. Running the tool in Civil 3D is based on selecting two points on a reference building footprint file (don't forget paying attention to elevation) and saving the information to a separate file.

Note that it uses a file formatted as ACCSXML (Autodesk Consulting Coordinate System eXtensible Markup Language).

The file is then used in combination with a plug-in tool inside Revit that asks you to pick the same points in Revit and then select the source file. As the project progresses, you can pass model data back and forth easily as long as you export by specifying the correct project units and Shared Coordinates each time.

You can watch a video at You Tube that explains how it works (9:53)

The process described assumes that the person deciding where the building goes is using Civil 3D which in my experience is not necessarily accurate. They'll ultimately be responsible or define it precisely eventually but the building location is often affected by a lot of things and roughed in by designers using an underlay of a survey and civil data.

It is also very important that the person using Civil 3D passes along the two key points on the building. If they get this wrong or we misunderstand them we’ll end up with a discrepancy when we potentially pick slightly different points. Of course this assumes that the civil engineer is not sitting right next to “us”, the architect or structural engineer. Connecting the information between all parties still boils down to someone deciding what building location is "spot on".

Check it out, might help your next project?

Shared Coordinate Post Summary

Updated: 9/9/2013

This is a summary of posts I've written about shared coordinates and related posts. They are listed from the most recent to the oldest. That doesn't necessarily reflect their relevance based on age at all.

2013 Project Base Point Manipulation
2013 Transfer Project Standards and Shared Coordinates
2013 Moving the Project Base Point
2013 Coordinating Projects Using Shared Coordinates
2013 Lock Down Shared Coordinates

2012 Reset Shared Coordinates
2012 Revit Level and Elevations

2011 Location Location Location
2011 Shared Coordinates and Copy Monitor
2011 Project Coordination - Early Days

2009 Autodesk University Virtual Shared Coordinates Class
2009 Shared Coordinates Features Disabled
2009 Starting Projects - Two Pieces of Advice

2008 Shared Coordinates and Other Trades
2008 CAD Surveys and your Revit Project
2008 Acquire Coordinates Confirm

2006 True Elevation and Position

Reset Shared Coordinates

There isn't an easy button to just eliminate shared coordinates in a project. You can move the Survey Point back to the same spot as the Project Base Point and then use Specify Coordinates at Point to reset the coordinates the file is using. Sounds like I just countered my first statement?

I'm referring to the relationship between files when you use Acquire Coordinates or Publish Coordinates. Once two files are sharing coordinates you can't really remove this relationship. If you remove the link and import it again (Auto - Origin to Origin) the relationship survives. For example you can try to Acquire Coordinates from the file again to "reset" them and Revit will say that it is already sharing coordinates with the file.

To remove (really more like replace) the relationship I use a new (empty) file that is based on the stock Revit template default.rte. I import this file and Acquire Coordinates from it instead. Revit can only acquire coordinates from one source file so using a different file resets it to match this new file. Now it is possible to acquire them from the original file after removing the C/M relationship.

Revit Level Elevations Project and Shared

Revit levels can show a project elevation or a shared elevation. The project elevation is the possibly arbitrary height of the levels relative to zero elevation, like in the stock templates. If you change the elevation of the project via Relocate Project (sleight of hand) or via Shared Coordinates (actual change) you can alter the levels to show one or the other. Via email I got a question that I've been asked before, "I want to show both on the level, both project and shared. Is it possible?"

The first off the cuff answer is nope. The elevation base parameter is a Type Parameter and the labels used in the  assigned annotation symbol family responds to the level, not the other way around. So while I could show alternate units in the same level annotation I can't show alternate elevation base settings. Time for workarounds?

My normal suggestion is to place spot elevations that use reduced graphic options so they just show a value. Place them on the levels in the views you need them in...set and forget. Hopefully it's in the later stages of documentation?

Another possibility is to use a linked project that has its own levels that show the Shared elevation instead. It's tricky though because it may be difficult to get the annotation to sit still, stay in the same correct locations in all views...according to scale and orientation.

If levels could be assigned to Design Options it would be another way to approach it...no joy there.

You could create new level types for each level and use either text in the annotation family (separate multiple families) or assign a prefix/suffix to the label and literally type in the shared elevation values. Yuk...double yuk...but it would give you the result most people want to "see". Need to double/triple check that before every print cycle though.

Along the same lines of yuk, double yuk would be text placed in views directly, possibly as detail groups to manage the data entry.

Anything I'm forgetting??

It would be so simple if it were possible to assign the elevation base setting at the label formatting side of the equation. So close yet so far sometimes.