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.

Tuesday, November 22, 2016

Add a Comment using Synchronize and Modify Settings

Whenever we need to use Synchronize with Central (SwC) I advocate for using the button for Synchronize and Modify Settings every time.


Doing so allows Revit to present us with the Synchronize with Central dialog.


I encourage everyone to take a moment and type a brief description in the Comment field provided. What motivated you to use SwC just now? That's the gist of what should be recorded there. I find that people are more receptive to making a habit of it once they see it can prove to be very useful to just about everyone working on the project.

We can review the comments anytime we choose to, even if we don't have a project open yet. That means that anyone who can at least fire up Revit can review project comments even if they don't really need to do any work in Revit.


Yes, the Show History button on Collaborate ribbon is awake even if no project is open. Click Show History, browse to the location of the relevant Central File and click Open. The comments are presented to us like this.


I doubt it is hard to imagine how having everyone on the project team recording comments (time stamp and username are stored automatically too) can be helpful for diagnosing issues, checking the status of tasks, and even a quick review of user activity on a given project file. It will also become obvious who isn't playing along pretty quickly.

I also recommend that we never use the other button for Synchronize Now (that's why I put the red X on it in the image above). It doesn't present the dialog so there is no opportunity to store a comment and equally important is that is does not relinquish User Created worksets automatically.

If you pay close attention you'll notice that all of the other kinds of worksets are automatically checked when the Synchronize and Modify Settings dialog is open. Those other worksets are relinquished with Synchronize Now, not User Created worksets though. If you use Synchronize Now and you've ever been accused of retaining ownership of these worksets...that's likely why.

If it helps:

Green Arrows in Circle SwC = Good!!
Lighting Bolt SwC = Not Good!!

If you're interested in taking a peek at Kinship's features you'll find that these comments can be reviewed at will with just a browser.

Wednesday, November 16, 2016

Kinship and Autodesk University

My friends Jose Fandos and Gary Sprague have been working tirelessly to develop a product they call Kinship. It offers an intelligent way to organize, search for and place Revit content and even more compelling to me is the project insight it can provide us. After a couple years of private testing they are opening things up for real.


They were kind enough to invite me along with them to Autodesk University (AU) this year. If you are attending AU please stop by to say hello and find out more about Kinship. If you're not here at AU then let me encourage you to visit their site to learn more.

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:

Files:
  • Master Site > Acquire Coordinates from Site/Survey
  • Master Site > Publish Coordinates to Architecture Model
  • Architecture Model > Publish Coordinates to Trade Models
Positioning:
  • 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