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

Friday, July 24, 2020

Revit 2021.1 Reset Shared Coordinates and Acknowledge Acquire Coordinates

I saw that Daniel Stine and Autodesk both wrote about the new point release for 2021. Daniel mentioned my past post about resetting shared coordinates because the latest update includes a new feature dedicated to that task.

I also wrote about Acquire Coordinates not rewarding us for successfully completing the task and they granted that wish too.

One of my post's was written in 2012, only eight years to get my wish. Glad I'm pretty patient.

Tuesday, December 05, 2017

Revit Coordinate Systems Video

A lengthy exchange at Autodesk's User Forums about this subject reminded me that I've meant to create a short video to describe how they relate to each other for quite awhile. This morning I saw our cutting boards drying next to the sink and realized they could serve as metaphorical coordinate system planes (Project and Survey) work in Revit. I am curious if readers find it helpful.

The original post at the forum dealt with a few projects that had been modelled very far from Revit's Internal Origin/Startup Location. I looked at one of the project files and found the Survey Point and Project Base Point had been moved very far away while unclipped. The modelling started there, really far far away. They started to experience some of the negative symptoms that can occur and started looking for solutions...thus the original post. The short answer is they needed to move their model closer to the origin. No other way around it.

Thursday, November 30, 2017

Link DWG and Named UCS

Working through a couple support issues recently it turned out that the presence of a Named UCS prevented us from linking a DWG using By Shared Coordinates. Revit would force the DWG to link using Center to Center instead. We tried all the things to resolve it first until we remembered to check this too.

This has been a part of Revit for a long time, the "REVIT60" in the name is the Revit version when it first appeared, Revit 6.0. When we use Publish Coordinates on a DWG file Revit creates this UCS so it can be used from within AutoCAD to ensure any external references that need to align with it will do so. We can delete the Named UCS in AutoCAD by right-clicking on the name.

We have more than one site related DWG for each project to align within Revit. We used Acquire Coordinates on our benchmark file. When all the related DWG files share the same WCS origin we can tell Revit to use By Shared Coordinates when linking them.

An obtuse but factually correct message appears telling us the files don't share coordinates.

Aligning the file based on its WCS is precisely what we want so each of the files align in Revit, possible, again, because we used Acquire Coordinates on the benchmark file first. That aligned the Shared Coordinates with it so the other files could stack on top of each other properly when we linked them.

There are many subtle things that can affect the linking process with DWG files, add this to the pile.

Tuesday, September 12, 2017

Clipped or Un-clipped - That is the Question

The question asked: "Steve, should we leave our coordinate system icons clipped or un-clipped?"

My Answer: As we know, the Project Base Point (PBP) and Survey Point (SP) can be un-clipped. If they are untouched we'll find them clipped.

When these are clipped the symbols for each of these are attached to the coordinate systems they belong to. That means moving either while clipped will alter the coordinate system. If this is done unintentionally, or by someone who does not realize they have been adjusted intentionally already, the coordinate system(s) will be changed.

Therefore I'd say it is not unreasonable to leave these in their NOT clipped or un-clipped state at all times, especially after they have been adjusted intentionally to align models or survey data. If they are not clipped then accidental movement of these icons do not alter their related coordinate systems. It merely changes the symbol's position relative to their coordinate systems.

I regard these symbols as markers or annotation when they are not clipped. In this state they are harmless to our coordinate machinations. Clipped they pose a danger to our careful adjustments to align models and site information.

My opinion: Keep them Not clipped, un-clipped.

Thursday, September 07, 2017

Shared Coordinates - Autodesk Reference Information

It's September posts in August...time flies.

This post is brief, merely a referral. If you struggle with understanding Revit's coordinate system then THIS LINK, at Autodesk's Knowledge Base (KB) site for this subject might be helpful. I like the images and some of explanations or interpretations it offers.

Check it out, it may help!

Edit: I wrote this on Sept. 7th originally, received an unflattering comment about it, returned it to draft, revised it, and restored it to published on Sept. 14th.

I was lazy. I thought the information was an addition to their formal help documentation. When I saw the comment I read through the KB article again and realized that it was written by an Autodesk User Group member and submitted to their Knowledge Base system, which happens to be curated by different people than the product documentation group. I might quibble with some subtlety of it here or there but its approach may help someone get a grasp on the bigger picture. Just keep in mind that its claims are not gospel, nor written by Autodesk's own people.

Friday, July 14, 2017

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.

Wednesday, July 12, 2017

Reset Shared Coordinates Update

During April 2012 I wrote about using a separate file as a diversionary tactic to allow us to reacquire coordinates from a model we used Acquire Coordinates on before; now that it has changed and no longer lines up with our own work.

In the years since that post Revit seems to have decided it should remember more than one file has had the Acquire Coordinates tool used on it. Revit used to be monogamous but that's no longer true.

The reset process is still necessary but an extra step is required now: we must deliberately disable the link's Shared Site setting first.

Usually it is necessary to move the linked file to align with ours and so its new position can be reacquired. If the setting isn't disabled first it will trigger Revit's desire to change the Shared Coordinate system of the link. Keep in mind that Acquire Coordinates is a pull transaction but moving a file that is sharing coordinates causes Revit to think it must push that change out to the related file. If that's what is really needed then consider using Publish Coordinates instead.

Select the linked file and in the Properties Palette click the Shared Site button (by default says Internal unless someone has changed the name). In the Choose Site dialog that appears click the radio button for Do not share site of selected instance.

It should say <Not Shared> like in the image above after choosing that option. It should be possible to move the linked file into the desired position so it lines up with our model correctly again. If it works correctly you won't get a warning to save the changes to the link nor will you get prompted to do so when you save the file.

It is now possible to link a Reset File to use the Acquire Coordinates on. As soon as that is done successfully the original linked file can be used to Acquire Coordinates again, from it instead.

If the disabling step was not taken we'd find that Revit remembers it has a shared coordinate relationship with both files, the original link and the reset file. Examining properties for both linked files would reveal a Shared Site setting in play (Internal) for both.

However, Shared Coordinates and its Survey Point only acts according to the last file Acquire Coordinates was used on regardless how many files Revit is keeping track of. Trying to use Acquire Coordinates on either file in this condition will just generate this warning.

It's almost as if Revit is treating using Acquire Coordinates like a marriage and keeping a record of each marriage, regardless how many divorces the file goes through. I'd recommend it moves on, focus only on the active marriage and make that work.

To recap - if you find your shared coordinate relationship has failed you'll want a divorce. Then you'll fall for someone else quickly, on a rebound, only to discover that your previous love was the best. Just remember you need to get a lawyer involved to disable your first marriage before you start your rebound. This way you'll legally be able to get married again when you come to your senses.

Monday, July 10, 2017

Revit 2018 - GEO Reference and Shared Coordinates

I replied to a thread at RFO that asked about Revit 2018 touting support for AutoCAD's GEO Reference feature.

On the surface, there is no obvious difference between how things worked in 2017 (or older versions) compared with 2018. Over the years you may have noticed that the Location Dialog, the one that allows you use a map to locate your project did not do anything at all related to the Shared Coordinate system. All that action did was provide a way for Revit to; originally calculate sun position (and therefore shadows) more believably and more recently to allow for energy analysis estimation to be done. Revit 2018, assuming the source DWG file is using AutoCAD's GEO Referencing feature, it is possible for Revit to inherit this data to affect not only the Location (Sun and Energy Analysis) but also the coordinate location of the project (Shared Coordinates).

The thread at RFO also asks about the 20 mile threshold Revit has regarding model size and warning us about model accuracy. The following is a restatement of things I've written in the past. Specifically they asked if there was any change to this in 2018. There isn't that I know of. I included the following to superficially explain the reason it exists.

The 20 mile threshold is a math and computer science problem that Revit developers choose not to lie to us about. They want us to keep the model as close to the file's mathematical origin as possible. External files (and internal modelling) that have data whose extents are larger than 20 miles begin to influence the accuracy of the calculations required to generate and display the model faithfully.

More often than not a civil file is not really larger than 20 miles. It just has elements that are farther away from the origin than that. Revit doesn't mind that issue and it doesn't mind assigning very large coordinates values to the shared coordinate origin (Survey Point).

It only cares when there are elements that are beyond the threshold. For example a file that only has two short line segments that are 30 miles apart will cause a warning. A file with an entire set of contour lines 40 miles away from the origin won't cause an error IF all the contours themselves and other annotation don't cause the extent of elements to also be larger than the 20 mile threshold. Distance from the origin is one aspect and the total extent (X,Y AND Z) of the elements in the file is the other.

Ultimately, the error appears because they want us to know that this external data could negatively affect the accuracy of what we work with inside Revit.

I wrote THIS POST to discuss how I deal with survey files that violate the threshold. It starts out with one issue (transparent elevations/sections) that occurs when the threshold is crossed.

Thursday, November 24, 2016

Publish Coordinates and Inter-related Linked Files

I frequently have models that are organized in/by what I call a Master Site model/file. This file is the Parent in the shared coordinate relationship for all the children/siblings models/buildings that I link into it.

When model positions are changed in this parent file I find it is sometimes (often) necessary to use Publish Coordinates on all the linked models, even those that have not been altered. I've observed inconsistent results where sometimes the location of a linked sibling does not adjust (update) when viewed (as a link) within another sibling model. Using Publish Coordinates seems to force these linked files to refresh properly when a model is opened, even though it might seem unnecessary for those that didn't change.

As such, it is possible that seeing other linked files appearing to be out of alignment for this reason may motivate us to try to reset everything. Pause, breathe...try using Publish Coordinates on all the links first.

Friday, November 04, 2016

Multi-Discipline Shared Coordinates

In the past I've written that using or invoking Shared Coordinates is not required to keep project files aligned with each other. It only becomes an issue or necessary when each discipline's files are expected to align with models that are produced with software other than Revit and then viewed with other software like Navisworks.

It's my observation that the most common reason for invoking shared coordinates is trying to orient models with the site conditions. Civil and survey data doesn't come from Revit so that practically guarantees that the architectural model will need to deal with shared coordinates. It's only slightly less guaranteed that the other trades have to deal with it.

I briefly dealt with (a short summary) the inter-disciplinary relationship before in the second of these TWO POSTS and it's reasonable advice until the architecture team has to move their model again, relative to the site model. The Master Site and Building Model linked file strategy I prefer becomes tedious when the building has to be relocated; tedious more so for the other trades remaining aligned with the architecture model that is.

The root issue for this tediousness is the Acquire Coordinates tool. Once the trades use it on the architectural linked model any changes to the building location don't propagate to the trade's models well. The position of the architectural model shifts being respectful of the shared coordinate relationship instead of ignoring that and remaining in the same position based on the Project Origin, the way it was linked to begin with.

Coping with this tediousness, we can fix the alignment of models after the building has been moved by taking these steps:
  • Remove the architectural link
  • Reset shared coordinates
  • Link the architectural file again
  • Use Acquire Coordinates again
Alternatively the trades can avoid using the Acquire Coordinates tool in the first place. I did write about this in another POST before. It is a long post, and mostly words, so I'll take another run at describing it here with some images too.

The most important thing to do is mark a known location in the architectural model so the trades can adjust the location of their own Survey Point and then use the Specify Coordinates at Point (SCaP) tool. By known I mean, the North/South and East/West coordinates based on the survey data.

When the architecture model is relocated on the site the new Survey Point information needs to be captured to pass along to the team. In the images that follow I've used the same model (Tiny House) I used in the posts I provided links for at the beginning of the third paragraph.

In the following image we see a first pass at the location of Tiny House A. This image is taken from within the Tiny House A model after having used Publish Coordinates on it from within the Master Site model. In Tiny House A I opened the Location Weather and Site dialog to capture the rotation of the model (wrote it down). The coordinates I'm using are based on coordinates defined or determined in the survey by looking at the corner of the property boundary. In this example I made them up so the coordinate values were easy to remember.

Imagine now that the HVAC designer has already linked the architectural model into their own project using positioning option: Auto - Origin to Origin and started working.

The reference plane cross-hairs you can see under the Survey Point in the image that follows are in the architectural model. That's what I used to mark the corner of the survey's property boundary so I'd be able to tell the HVAC designer where that location is. Yes, I linked the Master Site model into the architectural model so I could see that location to mark it.

Earlier while preparing to start work they moved their Survey Point (un-clipped) to the intersection of my reference planes. Then using the coordinate values and rotation information I also sent them they use the SCaP tool to define the shared coordinate relationship it should have relative to site and the building (see following image).

In this case we also need to enter the elevation of 20'-0" because the building has been raised that much in the site model. Keep in mind that we will find that the building and HVAC model both are still at the project elevation of 0'-0". The shared coordinate relationship is where this elevation is defined.

Now we need to imagine that something caused the architecture team to decide the building must be in a different location. The model was moved in the Master Site file and its new location saved when prompted. Now I've opened up the Tiny House model again and I can see where the Tiny House is. I capture the rotation values like I did before. I moved the Survey Point (un-clipped) even though it wasn't necessary. I do need to move the reference planes to mark where the common benchmark is located now.

I've posted the revised building model for the HVAC designer and sent them the new rotation information. The coordinates of the benchmark remain the same...the site hasn't changed after all, just the building's location relative to the site. Using SCaP they enter the new information after moving the Survey Point (un-clipped) to the intersection of the reference planes.

From all three models (architecture, HVAC and site), I've exported NWC files from Revit for use in Navisworks to see how they line up. In the first design iteration they were all on the other side of the site and in this image I can see they (building and HVAC) have moved together to the new location. I've hidden the wall and roof so the duct is visible. The green sub-region is just to mark the property boundary.

If the design requires the building to be moved again, once it has been moved in the Master Site file it is just necessary to repeat the adjustments I've described. This way each discipline's models stay aligned with each other based on using the positioning option: Auto - Origin to Origin.

A summary of the process:

The architecture team is in charge of positioning and they:
  1. Create Master Site
  2. Link Building
  3. Position, orient and elevate the building (or Reposition)
  4. Publish Coordinates (or Save Change)
  5. Identify a bench mark in the building model (or adjust to mark new location)
  6. Capture (record) and then provide coordinates and rotation/bearing information
  7. Share model with trades
If the building location has to be changed repeat 3-7 (differences noted with parenthesis).

Trades take the following steps:
  1. Link architecture model using Auto - Origin to Origin
  2. Place un-clipped Survey Point at agreed upon bench mark
  3. Enter Coordinates and Rotation (bearing) using SCaP
When building is moved on site trades repeat steps 2 and the rotation part of step 3. Remember to use/specify Shared Coordinates when exporting from Revit.

It is important to note that ALL of the above is biased for separate firms managing model relationships.

When all the trades work in one firm the Acquire and Publish Coordinates tools work better because all the files belong to us and we have concurrent access to them on our network. This allows us to link trade models to the architecture model and then use Publish Coordinates to pass along the information we have to manually keep in sync using the approach described above.

In the single firm the process and position logic can play out like this:

  • Master Site > Acquire Coordinates from Site/Survey
  • Master Site > Publish Coordinates to Architecture Model
  • Architecture Model > Publish Coordinates to Trade Models
  • Master Site - Survey positioned using Auto - Center to Center
  • Master Site - Architecture Model positioned manually
  • Architecture Model to Trade Models positioned Auto - Origin to Origin
  • Trade Models to Architecture Model positioned Auto - Origin to Origin

Tuesday, September 27, 2016

Survey Point Values after using Publish Coordinates

A RevitForum member remarked that it was confusing to see that the Survey Point shows 0,0,0 after using Publish Coordinates.

The image above shows the initial position, in a Building file, of the PBP and SP after using Publish Coordinates to pass the Shared Coordinate system information from a Site file to it. You can't see a building because they are quite far apart...which is why the icons do not change size when you zoom in/out.

When we open the Building model the Survey Point (SP) is marking its own origin, which is 0,0,0. When we examine the Project Base Point (PBP) we'll find coordinate values that indicate how far away it is from the SP. If we un-clip the SP we can choose to move it closer to the building and we'll see the coordinate values change to show how far the icon is moving away from its origin .

When we use Acquire Coordinates Revit moves the SP (when it is Pinned) to mark the location of the World Coordinate System origin (WCS assuming a DWG site source). When we use Publish Coordinates on the linked Building file it does the same thing but remember the SP is marking the WCS origin, which is 0,0,0 in the DWG...and for the SP of the building model too.

I hear and read the following a lot...
I then test it by removing the linked building model and re-link using shared coordinates and it works.
If you're tempted to do that, just don't do that on real projects since it opens the door to messing up the work we've just done. Just link the building model, re-position it and use Publish Coordinates. Then leave it alone; unless design changes require it to be moved again. A better test? Link the Site model into the Building model using By Shared Coordinates. That doesn't change anything you've done and you'll see they line up properly.

Placing a few spot coordinate annotations on this fine building design, after zooming in closer, looks like this. Also, the one closest to the PBP is assigned to PBP while the others are assigned to the SP.

Sunday, April 17, 2016

Orientation is not Managed by View Template

When we choose to assign a View Template (VT) to a View, that makes the template the view's boss. It takes over control of each setting we choose to make it enforce. In this image notice the parameters that are gray, not editable?

Those are being managed by the View Template. I've got to edit the VT to change one of those parameters or use Enable Temporary View Properties to override them briefly.

I noticed yesterday that the Orientation parameter does not behave like other View Properties even when a VT thinks it is in charge of it. This is the VT's dialog showing it is currently assigned to Project North; we can choose either Project North or True North. The check in the Include column (on the right side) indicates we want the VT to take over.

Therefore I find it counter intuitive that we can still interact with and change the Orientation parameter in the Properties Palette even though the VT is in charge.

If the VT is changed the view will follow along as expected. I wouldn't expect to be able to change it back in the View's properties with the VT in charge, but I can. This means the Orientation parameter is affected (managed half-heartedly) by a VT but it isn't truly in charge of the parameter, not like it is for other parameters.

It is inconsistent, perhaps a bug?

Thursday, November 12, 2015

BIM Workshops Sessions and Data

I gave presentations at three of the four BIM Workshops this year. The first was in Omaha (August), the second in Anaheim (September), the third in Phoenix (October) and I wasn't part of the fourth event in Honolulu.

Indulging in a little historical review, the Omaha event is four years old now. However for its first two years it was called Central States Revit Workshop. It's founder, Carla Edwards, lived and worked in Omaha at the time. She attended the first Revit Technology Conference in North America hosted in Huntington Beach, CA in 2011. She told me that she was inspired and determined to bring that feeling home to where she worked and to provide that kind of experience to others but with a local focus, the region near Omaha. She found that there were many people eager to help her make it happen as well as sponsors willing to support it. I was happy to be able to speak at her first event too, and each of them since then.

A year later, after wrapping up the second event, she made a big life decision; moved to California and joined U.S. CAD, an Autodesk reseller based in California. She brought the event with her. Now in it's third year, with U.S. CAD's help they expanded the event to two cities; Omaha and Anaheim...and that brings us to this year, the event's fourth. Phoenix and Honolulu were both a single day of sessions while Omaha and Anaheim were two days of sessions.

This year the following people were designated with a national speaker role; Andy Jizba, Bill Debevc, Brandon Pike, Brian Mackey, Carla Edwards, Chris Faklaris, Chris Keck, David Magid, Eric Chappell, Kelli Lubeley, Lonnie Cumpton, Paul Aubin, Robert Bell, Me, Steven Shell and Tom Whitehead.

This meant each of us agreed to give presentations at two or more of the events. Each location also featured a selection of local/regional people who were chosen after being invited to send in their session ideas. That gave each BIM Workshop a broad reach while drawing on local talent too. It was a good mix this year as it has been for each of the previous years.

It has been my intention all along to post the files associated with both of my sessions here so people can check them out. I just waited until the last event was concluded (and I needed a little time to update the documents a bit)...and here they are.

Session: Who Moved my Cheese?
Description: There are over 30 ways to lose something you’re sure was just there. Revit offers so much control over the way things can be seen that we need a chart or list to figure out what happened to them. This session will explore those and provide an opportunity for some group therapy (troubleshooting).

I organized this as a game show to get people directly involved in the class. I selected two contestants for each visibility problem (25 problems in all). They competed for Smarties (yes the little discs of sugary goodness). I was inspired by a challenge that some of the Autodesk Revit technical support team created for a past Autodesk University. They had a booth outside of the classroom areas where people could stop by and meet them. They encouraged us to take part in this Find my Chair challenge which included some pretty diabolical, even despicable, ways that someone could hide a chair. For example, one chair was a family that had been completely stripped, just an empty file now, and reloaded. If someone did that in your office you might be inclined to encourage HR to get involved?

My session wasn't nearly so mean. It was fun to do it. I've heard from quite a few people since that they enjoyed it too. Thanks!


Fwiw, since I ran it as a game show with a winner and loser for each round, more than a few people suggested that I should have awarded each round's loser with a Dum Dums, I did think of it...but I didn't want to harsh anyone's mellow.

Session: Shared Coordinates: Stay Out of the Rabbit Hole
Description: It seems simple enough. Then something goes wrong. There are a few too many ways that we can manipulate this information. People often make assumptions about how it should work but don’t fully appreciate the consequences. Let’s explore the subtleties and avoid falling down the rabbit hole.

In this session I described and demonstrated using a master Revit site model to provide the basis for the real world location of a building or buildings. Then I linked separate Tiny House models (yes, inspired by Sean Burke's own Un-Boxed House project). If you've been reading this blog for long you'll probably recognize the information as being derived from a series of posts I've written here before. As much as I'd like to think every Revit user has read my blog, there are a lot of people out there who have no idea just how much information about Revit is lurking out here in the internets. Then again, maybe they just have a healthier balance in their lives?


I hope that these prove useful or interesting. Let me know if you have your own Who Moved my Cheese Game show sometime.

Oh, Carla recently let me know that she's decided to accept a position with an architecture firm in Denver so she can get closer to project work again AND importantly be much closer to her family. There is that notion of balance again... I wish her all the best and I'm sorry she'll have a lot more snow to deal with there than here in Southern California.

Keep an eye on the BIM Workshops site for next year's details as they become available.

Wednesday, May 06, 2015

Revit 2016 - Rotate Project North

Technically this isn't a new feature. It’s an improvement of the existing tool. In the past this tool did not faithfully rotate all annotation elements consistently. We’d often find some annotation was either not rotated at all or moved into different positions. They've revisited the code to ensure more consistent results. It’s not a guarantee they've resolved everything since they can only tackle issues that have been identified as problems. We are pretty ingenious at doing things with Revit that the developers didn't imagine. Hopefully we’ll find that it is more reliable when/if we need to use it.

Let me take this opportunity to remind you that Revit’s bias has always been to create a model or building with Project North in mind FIRST. FORGET about the real orientation on site, initially (please). That’s what using Rotate True North is for and Acquiring Coordinates.

Those tools existed long before Rotate Project North. In fact it was only added because people can’t seem to remember to start their project using a Project North orientation. If you’re interested in more of my writing about using Shared Coordinates you can check out my blog post summary.

Saturday, April 11, 2015

Shared Coordinates and Collaboration for Revit

I've not written anything about Collaboration for Revit (aka C4R) yet. It's a recent development that puts a project in the cloud to give a project team access to the project data regardless where they are.

When it comes to Shared Coordinates, the Publish Coordinates tool is disabled. Acquire Coordinates does work.

As I understand the issue, Publish Coordinates is the only time that Revit has to be able to write changes to a linked file. The current A360 and C4R infrastructure doesn't support allowing that to happen...yet. They do understand it is something we want and need to do.

Regardless I'd still use Acquire Coordinates on a source survey file within a Master Site file, as usual. Then I'd link any building files and position them on the site, just like I'd normally do. To cope with the loss of Publish Coordinates I'd put location markers (a unique family for example) that allow me to figure out how to link and align Master Site in each building correctly afterward.

As I just mentioned, in each Building file I'd link the Master Site model and move, rotate and elevate it as required. Then I can use Acquire Coordinates and pick Master Site. This will pull the correct Shared Coordinates into the building model. I'd repeat that for each building.

I'd do the little building position dance in Master Site even though I could probably figure out how to do the reverse (position Master Site in each Building) somehow. I'd find it a little easier to work out each building's relationship to the Master Site model this way, seeing them all together at the same time in Master Site. I think it provides for better context.

When other trades get going they just need to link the Architecture model using Auto - Origin to Origin and then use Acquire Coordinates, picking the Architecture model. It's a cascading nested understanding of the survey coordinates, using Acquire Coordinates all the way down.

SMEP-Models - AC from - A-Model - AC from - Master Site - AC from - Site Survey

When they return their files to the architect they just need to be linked using Auto - Origin to Origin too. Technically if they do use Acquire Coordinates using By Shared Coordinates would work but if they didn't Auto - Origin to Origin is long as they understand it is important that they start out using Auto - Origin to Origin themselves, when they link the architecture model.

Tuesday, April 07, 2015

Survey Point - Post 4 - Acquiring Coordinates and View Orientation

The bias of the last three posts has been on creating a Master Site file and linking building models to site. That's moving buildings on a fixed site versus moving the site under fixed buildings. The earth doesn't go anywhere, we put buildings on it, so to speak. That bias feels right to me, the ways things really work.

These are links to the three preceding posts.

If you choose to take the reverse approach, link the site to a building, you have to adjust the survey information to align with the building; since its harder to move the model elements around than the survey file. In this example, I've started in a Floor Plan view assigned to Project North.

At this point is doesn't look much different than images early on in the other posts. The building is oriented conveniently for putting in on sheets. I need to move and rotate the survey DWG into a better orientation. I'm using the same preferences I had in the previous posts.

Now I just need to shift the survey down since the contours are at their actual elevations and the building model is at an arbitrary ground floor elevation of zero.

I used the same 22 feet for the ideal ground floor elevation I chose in the other post.

Now I'm ready to use Acquire Coordinates. I opened up both the floor plan and site plan views so I can see the change occur. I used Acquire Coordinates in the floor plan: Level 1 (that's a moment).

Since there are few possible combinations of actions, let's imagine that I used Acquire Coordinates a little differently. In this case I Acquired Coordinates in the floor plan view: Site and I wasn't observant enough to notice that the view is assigned to Project North which ordinarily wouldn't make sense to do, to me at least. It's easy enough to overlook because at this point the building orientation is technically the same as it is in other views assigned to Project North.

After I Acquired Coordinates I noticed the view didn't change so I realize it needs to be assigned to True North. I do that and the model rotates to show the orientation based on the survey's coordinate system, as I expected initially.

Now a little time passes (we're pretending). I find it necessary to use Reload to update the linked survey file, maybe I cleaned up some of the layers to make it a little lighter in our model. When I click Reload this happens. The survey spins out of alignment.

The cause is subtle and simple: it is IMPORTANT to respect the Orientation parameter setting used, in the view that's used, when Acquire Coordinates is used. If you change to the opposite setting and then Reload the link the orientation of the link will change undesirably; regardless of the view you happen to be using during the reload process.

To restate the cause and effect, I used Acquire Coordinates in the Site view while it was assigned to an unnatural orientation setting of Project North. I then changed it to use the more logical True North but AFTER I already used Acquire Coordinates. This means I have to remember to change it back (to Project North) EVERY time before using Reload on the Linked survey file... Or I fix it, which would require resetting the coordinates so I could Acquire Coordinate again with the better settings in place.

I believe this is another good reason to use a separate Master Site project file. The survey is linked and moved into position but it isn't rotated to reflect True North because UP is North already. The quirk I've described only affects the links rotation and there is no need to rotate it in the Master Site strategy.

Monday, April 06, 2015

Survey Point - Post 3 - Five Minutes with Shared Coordinates

I created a video that goes through the process I described in the previous two posts. It is set to a four and half minute song by Michael Lee Firkins called "The Window". If you've never heard his music I believe you owe it to yourself to check him out, very talented and unique sounding guitarist and song writer.

Survey Point
Survey Point - Post 2

Saturday, April 04, 2015

Survey Point - Post 2

Yesterday I ended the post with a list of steps that I'd take to create a relationship between my building project file(s) and the Master Site file. I started another pair of projects that I'm calling Tiny House A and B (inspired by Sean's Tiny House project). I can start a project with or without site context. Revit's bias is making the project easy to document, forget about True North initially. It is trivial to resolve that in the Master Site file once it is ready, regardless if it is created before or after the tiny house models are started.

Here's how far I took the design of Tiny House A before I decided to work out its location on site.

I closed Tiny House A's project file. I opened up my Master Site file and linked Tiny House A using positioning: Auto - Origin to Origin. The choice for positioning at this stage really doesn't matter since I'm going to move the file to another part of the site anyway; have to pick something so I just let the default option reign. In the following image you can see Tiny House A is sitting at/near the Master Site's origin, marked by the Project Base Point icon.

Now it's time to move Tiny House A into position. I moved it and then aligned it with the East boundary. Then I was careful to put it at 8'-0" from that boundary. I then made sure the closest corner (wall) of the house to the North boundary was also at 8'-0". Being fussy about this isn't particularly important, I'm just being fussy.

Now I want to make sure the house is at an appropriate ground floor elevation. I created a section view so I could see the site's contours and the floor of the house. I can see here that the house is buried under a fair bit of the site.

I decided that raising the house to 22'-0" feels good. I used the Move tool, and typed 22 into the temporary listening dimension that appeared.

I think I'm ready to deal with Tiny House B now. It's really just another project file saved with a new name. I was too lazy to make another design. If this was a real project I wouldn't be able to get away with that. I decided that this house has to be no closer than 8'-0" to the North boundary but I've also made the North end of the house parallel to the boundary.

I learned while reading the development's covenant and zoning requirements that these houses can't be closer than 15'-0 to one another. I decided to put Tiny House B 18'-0" from A. I heard that A's owner is a drummer so those extra three feet might help keep B's sanity. I also decided that the ground floor elevation for B should be 20'-0", a little bit lower than A.

Now that I'm satisfied with the positions of Tiny House A and B I'm ready to use Publish Coordinates. This tool will PUSH the site orientation information to each house's project file. Revit will use this information to shift the house's Shared Coordinate system to align with the Shared Coordinate system of Master Site. In yesterday's post, the Master Site was manipulated to be in alignment with a linked DWG file's WCS (the World Coordinate System in AutoCAD to be precise) through the use of the Acquire Coordinates tool.

When you successfully select a linked file to Publish Coordinates the Location Weather and Site dialog appears. This give us an opportunity to provide a meaningful name for the location we're creating for that model. I clicked Rename... and typed Tiny House A Location 1.

It's significant to appreciate that I could now create a copy of Tiny House A in Master Site and place this copy in another location. I could then use Publish Coordinates on this copy which would allow me to use Duplicate... and use another name like Tiny House A Location 2. In the Tiny House A project file I can now choose between these two named locations and make one of them current. Revit will reorient everything to show the building correctly for this location, all without really changing anything  in the model. It's pretty clever and powerful; actually doing it is something I'll save for another post.
I used Publish Coordinates again but on Tiny House B and used the name Tiny House B Location 1 when the dialog appeared. I'm ready to return to work on my Tiny House A design. I clicked Save so I can close the Master Site project. The following dialog appears twice, once for Tiny House A and the second time for B. This is confirming that I want to commit the location and shared coordinate changes I made while using Publish Coordinates. I clicked Save each time (2x), the top option in the list.

It is necessary to make sure others are not working on the Tiny House A or B now. The Save will fail if someone is working on them. Just ask them to close the project for a minute. When worksharing is involved the same is true but it is a bit more forgiving. Either way, if an error message appears you need to ask others to stop working on these files briefly; they need to Save and close them. Once my Save is completed they can get back to work.
When I open Tiny House A I find that the Site plan is oriented to True North. I changed the Orientation parameter to True North earlier (noted in the image at the beginning). All plan views in the stock templates are assigned to Project North, including the Site view. Changing it meant that I'd see the results of using Publish Coordinates immediately, or at least as soon as I bother to open the Site view. The reality of this is that the project is NOT altered materially, no physical change to any geometry, it is just oriented correctly based on my actions in Master Site. This trivializes the task of re-positioning a building on site, if that becomes necessary.

Taking things a little further, each Level type has a Type Parameter called Elevation Base. It can be assigned to either Project Base Point or Survey Point. When I change this to Survey Point I find that the levels are reporting elevation values based on how much I raised Tiny House A in the Master Site file.

Now I've decided I want to be able to see Tiny House B here too, for context, but while working on Tiny House A. I linked Tiny House B into Tiny House A using positioning: Auto - By Shared Coordinates. This is possible because I used Publish Coordinates, from within Master Site, on both Tiny House A and B. Their shared understanding of their position in Master Site makes it possible to link either file into the other using Auto - By Shared Coordinates and they land in the correct spot relative to each other.

I can also link Master Site into either Tiny House A or B and use Auto - By Shared Coordinates too. They all understand their relationship to each other because of Publish Coordinates and the work I did in Master Site to put them into the proper context with each other. Here is Tiny House A, with Tiny House B linked in. I also created a Toposurface and Building Pads for each house in the Master Site file, then I returned to Tiny House A so I could link Master Site in using Auto - By Shared Coordinates as well.

A Few Notes
  • Master Site is in CHARGE of positioning
  • Only move models in Master Site
  • Do not move linked models when viewed in other related project files
  • Acquire Coordinates created the relationship between Survey and Master Site
  • Publish Coordinates created the relationship between Master Site and Tiny House A and B
  • Respect this order and it is easy to maintain
  • It is technically possible to manipulate the relationship in either direction, DON'T.
  • You must Resist the temptation!

Multi-Discipline Comments:
  • Trades link the Tiny House A and B models into their projects using Auto - Origin to Origin, nothing else.
  • Do NOT start work without a preliminary model of the Tiny House. If you do, be prepared to move your work into alignment manually.
  • It is only necessary to use Acquire Coordinates on Tiny House A or B (whichever house you are designing for in your project file)
  • It is only necessary to use Acquire Coordinates IF there IS an expectation that your data must align in 3rd party software like Navisworks
  • The Tiny House projects will link your models using Auto - Origin to Origin too

Friday, April 03, 2015

Survey Point

In my view, it is no accident that the Survey Point (SP) is named using Survey. It's purpose or role in Revit is to permit us to relate our project to survey coordinate data, which is ordinarily provided by linking an external file. This image depicts a linked DWG site file whose origin is roughly 85 miles from the southwest property corner. The iron pipe at this corner has X/Y coordinates of exactly 450,000',450,000'.

It was imported using Positioning: Auto - Center to Center. This is what Autodesk recommends we do with files that are far from origin. Place the survey information close to the Project Base Point (origin) of the project. Then I used the Acquire Coordinates (AC) tool which was created to let us PULL this information in from the external (linked) source.

After using AC the Survey Point (clipped) marks (makes it easy to see) the actual origin of the source survey data's origin. It is why it usually disappears off into the distance, in stark contrast to where the project's origin is.

When the SP is un-clipped and dragged away from the origin, presumably closer to the project's site, it begins showing coordinate values that equal its offset from its origin, the origin is not altered/moved.

This is what the project looks like after I've finished adjusting the position of the unclipped Survey Point. At this point I only regard it as a marker that validates my belief that my Revit project is now aware of the same coordinate values as, and aligned (in sync with), the linked Survey file.

At this stage I save the file as my Master Site file. This file will act as the Control for site relationships with the site for any and all related building files I may use for this project.

Next (in a follow up post):
  • Import a building file
  • Position it (X/Y)
  • Orient it (rotation)
  • Raise it to the appropriate Ground Floor elevation
  • Publish Coordinates
  • Repeat for other buildings

  • I'm intentionally NOT interested in the Project Base Point in this post
  • I intentionally did NOT move or alter the Project Base Point
  • I WON'T move or alter the Project Base Point in this file EVER.
  • I WILL turn off the visibility of the Project Base Point.
  • Shared Coordinates are NOT a Band-Aid, to fix poor communication/alignment

Thursday, March 12, 2015

Follow Up - Importing DWG Files using By Shared Coordinates

As the title suggests, regarding an earlier post earlier post, recently I was participating in a thread at the Autodesk User Groups and an Autodesk support person wrote that Revit intentionally attempts to create a User Coordinate System. This means what I wrote about in the other post is happening on purpose, not a bug.

This means they (Revit's developers) are assuming the files we are linking don't already share an agreed upon file alignment strategy between the people that created them. If I understand their logic, it means that using Positioning: Auto-By Shared Coordinates when we link a file triggers a response in Revit that it needs to create a UCS (User Coordinate System) to permit AutoCAD users to align these files if they are combined (apart from Revit) in AutoCAD at some point.

Revit can't know if these files have an agreed upon relationship to the WCS origin because in AutoCAD that's a subjective user based agreement, not something captured in code. In other words we agree as users to draw things relative to 0,0,0 in a specific way so our files will line up when we use them as an external reference. In my view, for multiple survey file relationships, that's most likely not necessary and just creates confusion. I can imagine how it might be useful if we are mixing a variety of trade files that might not have discussed how their work relates to the WCS origin. However that seems like a rarer circumstance to me, especially if Revit happens to be the primary platform in use.

Imagine we link a survey file into our Revit project and use Acquire Coordinates. Revit establishes a relationship with this external file and moves our project's shared coordinate system to align with the survey file. It moves the Survey Point (when the icon is clipped) to mark the WCS (World Coordinate System) origin location of the linked file. Now imagine we link a DWG file that, to pick a discipline, is the fire protection design. It isn't very likely that they started designing by importing the survey DWG. That means their file and the survey file don't share in their understanding of how to start drawing relative to the WCS in their AutoCAD files. In my opinion it is much more likely that they started designing based on a plan we exported from Revit and sent to them. If true then we'd be better off importing their file using Positioning: Auto - Origin to Origin.

If they just started designing without a background file from us (not really likely, what context would they have?) then we could link their file using Positioning: Auto - by Shared Coordinates. Revit generates a warning (refer to the other post's images) that this project isn't sharing coordinates with this file so it will import it using the WCS of the file, which is still pretty arbitrary in this scenario. Revit however regards this positioning choice as significant and when we try to save our work it prompts us to save the changes to the linked DWG file too. It wants to create a UCS in that file and save it so that an AutoCAD user can reference it, making it possible to line up this file with the survey data if those files are combined in AutoCAD.

In my view this a feature that is conceptually broken. It is changing a file (creating a UCS) that isn't the primary file, just my copy of it. They sent it to me so I can link it. If all of the disciplines work at my company and in my office then perhaps all the files are stored on the same server and accessible to everyone. That's certain possible but it is still unlikely that this UCS will be necessary or that anyone will even be aware that it exists.

The shorter answer, when confronted with this dialog: Choose Disable Shared Positioning (for the file involved, not the one that was used to Acquire Coordinates originally).

Based on my bias, we should have a way to tell Revit we want to link a file based on the Shared Coordinate system without incurring the belief that a UCS must be created in the file too. Perhaps an option to link via the WCS of the external file and the origin of the Shared Coordinate system without the assumption that we think there is actually a shared relationship between the Revit project file and the DWG file?