Our example includes a project with multiple small buildings in one file, at the correct elevation and location on a site. One building's ground floor level sits 3' higher than an adjacent building. Normally, when you set a project up, you would link the architectural model, then copy/monitor the levels from the architectural model to have one common set of levels. From the copied levels, you would create a floor plan view for each level, for each building.
Now stop and think about this - how would you do it in 2D AutoCAD? You'd take a site file showing the buildings, and either do a separate drawing for each floor plan (old school) at 0,0 in each building. But if you were doing both buildings in one CAD file, you'd be tempted (hold on) to create one plan viewport around one building on a layout tab...then copy the viewport, and pan over to the other building...all while keeping that viewport the nice, same size. This results in EPIC fail on the BIM test.
In 2D CAD, you can get away with this - but you can't do this in Revit - why?
Simple - every plan view is associated with a level, in most cases, a primary datum level at a specific elevation. Everything you place in the view is related to the level associated with that plan. Even hosted items can give off data that relates to the floor plan level, such as an offset elevation on a wall. But if you take a view that's associated with one level, and simply change the crop region around another building (which has a primary datum level at a different elevation), it's going to be wrong.
So here's where the problem occurs. For example - a user adds a pipe thinking that 210 Basement has the 210 Basement level as the associated level. So they're drawing a sloped pipe to what they think is 7' above that level. But in the view, since the 210 level is actually 3 feet lower than where it really needs to be. So the pipe is drawn at 10', not 7', causing additional work needed to change the pipe to the correct elevation.
You can change the associated reference level to get the right elevation, but it's something you're forced to stop and think about...and do a little math. Make it a really odd number...and you're really messed up.
And guess what - you can't change a plan views associated level once it's defined. (BTW - I did try to do this with a view list, by including the associated level...but no joy on that approach). You can also screw this up on single building projects - by copying a lower or upper level plan, and then changing the view range for the view properties. This is also a massive fail - since non-hosted objects display relative offset heights from the associated level...ugh...
So the fix for the user is to create a new view that's associated with the correct level, and then copy and paste generic annotations like text to the new view. Tags and dimension should be re-created, but these guys are pretty quick to make again.
In the end, it boils down to a simple thing - when you are setting a project up - whether it's one building or multiple buildings - make sure you start by creating a primary floor plan view for each level. Make sure it's associated with the correct level. If you are duplicating views to save some time, ALWAYS check that associated level. This keeps the issue from spreading like a virus to the rest of the project.
PAY ATTENTION to the details...cutting corners catches you every time...
later - David B.
No comments:
Post a Comment