Showing posts with label Trades. Show all posts
Showing posts with label Trades. Show all posts

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

Tuesday, August 27, 2013

Linked Ceiling Hosted Light Fixtures and MEP

A ceiling hosted light fixture can cut the host ceiling. When an architect uses one of these fixtures the ceiling surface the Revit MEP user has to work with actually has a "hole" in it. This means that they can't put their own light fixture in the same spot because there is no ceiling there.


Technically that's an oversimplification. We CAN put a fixture in the same location but there isn't a face for Revit to detect easily. If you try to use the Downlight - Recessed Can family it's origin is too far from a ceiling's grid pattern to let us put it within a tile. We can put it in randomly and then move it to the correct location. We'll get yelled at though, the light isn't properly hosted now.


If we do the same sort of thing with the troffer family (2x4 fixture) it will be a bit more tolerant as well as not losing its face association.

This sort of discipline collaboration isn't tons of fun.

Friday, February 04, 2011

Project Coordination - Early Days

This post attempts to outline how a project will develop (understanding there are exceptions) when considering multiple firms/models and attempting to keep each model aligned both in Revit's model environment and relative to the site location and survey information. It differs from previous explanations I've offered here because the separation of models tends to challenge the traditional Publish and Acquire Coordinates tools. These tools work more readily when all the models co-exist on the same network, shared among the team. Less so when that isn't possible.

In the beginning..."You" (an architecture firm) start your project without a reliable survey. Sometimes the survey is a hand drawn document from a "couple years ago" or it's just a legal deed description. Maybe it is just from a survey you don't trust? Regardless you are less than excited about relying on it completely. Someone arranges for a survey or less convincingly...one is being promised.

Using a new project template (your killer office template of course), start your Revit project at (near) the origin in Revit (project basepoint). Don't even worry about the survey information for the moment. Draw the concept so it is easy to put on paper, on a printed sheet. Doesn't matter if it is angled or new fangled, just orient it so it is "easy" to draw.

When the survey comes in or you are forced to do some site documentation (guessing) create a new Revit project file (for example call it: Site Master or Master Site) and create whatever information you intend to use in this file. The presiding reason to create this separate file is to minimize the pain and suffering should the building location change or if there is more than one building involved. Work in this file, orienting everything with North as the top of the view, North is "UP" (like World Coordinates "WCS" in AutoCAD).

You also need to match the coordinate system of the Master Site Revit project to the survey. The most reliable way to do this is to agree on a benchmark location in the survey and use those values with the Specify Coordinates at Point tool to define that same spot in Revit. The reason it is most reliable is that large coordinate values do not get extracted properly using the Acquire Coordinates tool. Safer to use the one that "always" works, I think. When the survey is imported into Revit use Auto-Center to Center so that it is near Revit's own origin. Then the Specify Coordinate at Point tool will adjust the Survey Point to indicate where the survey 0,0,0 (origin) is. If you "un-clip" the Survey Point first you can use it to mark the benchmark and it won't shift to mark the survey origin.

Now that this file exists you have some understanding of the site and hopefully have an idea about where the building ought to go. Import your building model using Manual at Origin and "plop" your building somewhere on the site. Move it into position, align/rotate it and raise it to the ideal ground floor elevation (literally move it up/down in a section or elevation view). Once the building is where you believe it should go you can define the important site information to share with everyone else. Contrary to typical convention don't bother with Publish Coordinates. More on this in a bit, hang in there.

Let's pause, back up and insert some stuff between the building model and the site model coming into being, before you get reliable site information (or faking it).

Let's assume you decide to hire a structural engineer (and MEP) and they use Revit too. You send them a copy of your model (remember, before any notion of real site position information). They import your model Auto-Origin to Origin. The reason for this is that the extent of your model is likely to be different than the extent of their template. Using Auto-Center to Center will not guarantee that your origin and their origin are at the same place. You want the Project Base Point (Revit's project origin) to be the same in both files. The MEP consultant does the same. The engineers match up their levels and grids to yours using Copy/Monitor (most likely...or probably should).

At this point everybody has models that are at the same location from one Revit file to another. Importing any file into another will end up at the same spot in each other's file. If you never deal with site you are all good to go.

If we assume that you and the engineers have traded files a few times we can reconcile the site conditions when they become available. When a real survey exists (or even a fake, good enough for now one does) you add it to the site master file and use it to define (as described earlier) the actual coordinates so the master site model and the civil information are in sync. Assuming you have to adjust the building you do it here, in the Site Master file. Move it, align/rotate and raise/lower it but as I mentioned before, DON'T bother using Publish Coordinates.

When you are passing models back and forth the process (FTP/Uploading/Downloading) of publishing coordinates breaks down if/when your architecture model has to be moved on the site. The relationship between the site and your model is easy. Not so easy for the other models and your model to say in sync. The goal should be to keep the project origin intact between files. Instead of Publish Coordinates, we will use the Specify Coordinates at Point tool to tell each project file what the site information is. This is done by determining what the necessary information is in the Site Master file and passing it along to each team/model. It's a simple list: East/West & North/South Coordinate for a established location like Grid intersection A1, Elevation at that location and the building Rotation relative to East or West. It looks like this when you've got it entered into a building/structure/mep model.


You extract this information from the Site Master file by using the Report Shared Coordinates tool at Grid Intersection A1 (or something agreed upon). This gives you the E/W and N/S coordinates and the Elevation. Rotation is determined by finding the angle between True North and the Grid (or something) that represents Project North.

As mentioned above, you don't actually publish coordinates or acquire them. You use Specify Coordinates at Point in each model to tell Revit what the real world coordinates are at that point (Grid A1), what the elevation of the project is and what the rotation of the project is. As soon as you enter the information Revit "adjusts" the project but it never really moves. All the project views are intact. The only time that major changes are required by everyone are when the model itself is redesigned to different angles or shapes. It's hard to avoid that kind of rework. Repositioning the building on the site however is updated with much less trouble or downstream heartache.

You just repeat those steps if the site conditions or something forces a change and pass the new coordinates, elevation and rotation information along to the engineers. They use Specify Coordinates at Point, enter the data...back in sync. If they don't update the information the models still stay in sync between Revit files. The failure to do so only becomes apparent when the model is exported to Navisworks or a cad file for Civil to use.

In a flow chart the concept looks like this.


The coordinate data in the dashed boxes could be as simple as four lines in an email, like this:

The new project coordinate information is a follows
  • E/W Bearing: 1,500,000
  • N/S Bearing: 1,250,000
  • Elevation: 142'-0"
  • Rotation: 25 degrees Relative to: West

If there are multiple buildings involved the process is the same except they'll each have their own unique coordinate information ultimately derived from the building model located in the Site Master file.

This is my first pass at documenting this...so if I've missed something or described it poorly...I'll be back. I'm also planning on a video capture or two...