Announcement

Collapse
No announcement yet.

Two buildings, a contour map, and a site plan file. Best place to make sheets?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Two buildings, a contour map, and a site plan file. Best place to make sheets?

    I need some help figuring out the easiest way to organize sheets in a project. I've got two nearly buildings (Building A and Building B), both modular buildings with 10 suites in each. Building A and B are NEARLY identical, but the minor differences have lead me to create separate files, buildingA.rvt and buildingB.rvt
    I've got a contour map based on survey data in its own file, survey.rvt Finally I've got everything loaded into site.rvt

    So far, I'm finding it's more convenient to make the sheets in buildingA.rvt, as when I need to change things, I don't have to be switching between files. Though if a building C D and E are built somewhere down the line, is it really best to be creating sheets in buildingA.rvt ? It would make even more sense, I think, to be creating sheets in the site.rvt, where EVERYTHING is loaded in, but any time I want to make a change, I'd have to switch to the appropriate file.

    I could really use some input
    Thanks everyone

    #2
    This brings up the age-old debate about using a "Sheet Master" file, or to print sheets directly from the native model.

    I prefer printing directly from each model, then combining PDF sheets in Bluebeam. Trying to annotate via links is not a smooth workflow, as tags, dimensions,etc are prone to getting "orphaned" ( losing their linked model host) or worse yet, getting deleted.

    But I have seen it done both ways. To each his own.
    Cliff B. Collins
    Registered Architect
    The Lamar Johnson Collaborative Architects, St. Louis, MO
    Autodesk Expert Elite

    Comment


      #3
      Having a *sheet file* basically sucks in every way imaginable. I would do the sheets in each Building File.

      If those buildings get built *down the line* they are going to end up being under a different permit, with different revisions, and a bunch of other stuff that wont benefit much at all from being in one "sheet file" anyway.

      There are extremely specific situations where i do a Sheet File, but its generally reserved for an early release package that becoems 100% irrelevant after demolition and partial construction is done.
      Aaron "selfish AND petulant" Maller |P A R A L L A X T E A M | Practice Technology Implementation
      @Web | @Twitter | @LinkedIn | @Email

      Comment


        #4
        I have split up large buildings into linked files in order to prevent interior wall edits from affecting enclosure elements, or structural elements that get modeled by architecture. This is also necessary when doing a project with multiple towers that have different level elevations in order to avoid walls and other elements from constraining to the wrong levels.

        In these scenarios where do you create your sheets? No matter what, you will have to tag through a link eventually, or use linked views. One issue is that large buildings often have views that span these multiple zones, complete with the need to reference views from these zones, which of course cannot be done through a link. All of this points towards wanting to keep all sheets together, unless you start to create duplicate views in each link in order to reference the overall views, which is error prone, or start creating dummy annotation tags.

        Is there a way to avoid walls and other elements (rooms, etc) from constraining themselves to the wrong level in a single building with multiple tower scenario? Is there a way to stop walls, columns and beams form joining up automatically by default, which then means things get moved by inexperienced staff? I have tried worksets, pinning an other methods, but short of manually remembering to disjoin things there does not seem to be a sure fire way to prevent these issues when modeling all in one file.

        Comment


          #5
          The best integration of data in Revit is all in one model, the single model paradigm. Real life intrudes on the fantasy, thus linked files. If you need to put a significant barrier between elements then Linked File relationships do that. Revit has provided some respite from that barrier by permitting more access to linked elements via tagging, dimensions and graphic overrides. That doesn't change the fact that it intended for us to put it all in one place to be integrated well. There is a cost for every action taken to fix something by taking the linked file path...some are worthwhile and others aren't. It's going to vary from project to project and team to team. That's been my experience.

          Originally posted by ocrender
          ...Is there a way to avoid walls and other elements (rooms, etc) from constraining themselves to the wrong level in a single building with multiple tower scenario? Is there a way to stop walls, columns and beams form joining up automatically by default, which then means things get moved by inexperienced staff?...
          The best remedy for these things is knowledge (training and developing good habits). If users routinely do things without awareness of consequences that's a training and knowledge issue for a little while. If it goes on without improvement, after stepping in with training/reminders, then it starts to suggest a passionless appreciation of standards and working with others well. That ought to become an HR issue eventually. Who wants to work with people who don't respect what everyone else is doing? It's a cliché but the term Team Player matters in AECO, it's a team sport eh?

          Stepping back off the soapbox...

          Reminding everyone to pay closer attention to wall properties, paying attention to the options bar and turning on and off the Allow Join feature can go a long way toward proper level and element relationships. Inexperienced staff working on projects may be your reality but every time they do so without adequate training (first) and supervision and guidance (on going) is money out of everyone's pocket. When I got started in AEC mentoring was something the architects I worked with took quite seriously. It's a shame to see everyone is too busy to take it seriously now. It's to the detriment of the profession, no small thing.

          Edit: guess I only took one foot off the soapbox...
          Last edited by Steve_Stafford; January 25, 2018, 08:24 PM.

          Comment


            #6
            Originally posted by Steve_Stafford View Post
            When I got started in AEC mentoring was something the architects I worked with took quite seriously. It's a shame to see everyone is too busy to take it seriously now. It's the to the detriment of the profession, no small thing.

            Edit: guess I only took one foot off the soapbox...
            But we can just copy and paste, and use typical details for everything, and it's super easy and fast, and blah blah blah. I'm right there on the soapbox with you. :whiskey: I'm a big fan of mentoring and explaining why, rather than just 'Use this thing here' but it doesn't seem to be that common anymore
            Revit for newbies - A starting point for RFO


            chad
            BEER: Better, Efficient, Elegant, Repeatable.

            Comment


              #7
              Originally posted by cellophane
              ...I'm right there on the soapbox with you. :whiskey: I'm a big fan of mentoring...
              Well we all spend a lot of our time doing (trying to) exactly that in the forums eh? Cheers!

              Comment


                #8
                While I agree with you that some of this comes down to training, a lot of it is just bad software design. Revit creates a lot of constraints in the background, on its own. There should be more transparency to the user when that happens, and there should be an option to turn this off when not wanted. Revit is relentless is some of these relationships, and it causes a lot of rework.

                Inexperienced users coming into a Revit project is a reality, and even after training it takes years to get a handle on some these best practices. Often times users ignore the best practices (and workarounds) required to avoid these problems, because it takes extra time or requires one to remember too many steps. Revit needs to be more resilient in this respect. Right now its too much of a house of cards.

                Comment


                  #9
                  Originally posted by ocrender
                  ...While I agree with you that some of this comes down to training, a lot of it is just bad software design...
                  One person's garbage is another's treasure.

                  I can't dispute your own experience with the software and the people you work with. I can say that my own experience, at times, will concur with and contradict your claims (some specifics are necessary usually). That shouldn't be too surprising. As such, some of Revit's beliefs (constraint logic and bidirectional parametric relationships) are in direct conflict with your own (and others) beliefs about how it should all work.

                  It's like anything else in our lives. I can buy a car and have a terrible experience while other friends love the same brand/model car and haven't had the slightest issues. In my decade+ of supporting and teaching Revit I find that more/deeper knowledge and better habits pays dividends every time. Some of that is from the school of hard knocks, training classes, forums, conferences and so on. We can learn from it all. Some people insist on the School of HK even though they know better.

                  Ultimately venting and blaming the software might feel good but it doesn't change anything. Revit doesn't even care, it's just code after all. It runs a series of instructions precisely the way other professionals told it to. They do care! As such very specific feedback (here and elsewhere) can help guide those people as they work on Revit. How well our own beliefs and preferences match their own goals, timeline and beliefs is a factor too.

                  Comment


                    #10
                    Originally posted by ocrender View Post
                    I have split up large buildings into linked files in order to prevent interior wall edits from affecting enclosure elements, or structural elements that get modeled by architecture. This is also necessary when doing a project with multiple towers that have different level elevations in order to avoid walls and other elements from constraining to the wrong levels.
                    You have to be careful with the word *necessary.* It ISNT necessary in that case, thats the workflow you PREFER. And yes: If you dont use that workflow, then you have to do the work of checking that constraints are correct.

                    1. Exterior and Interior? I wouldnt ever separate them. And honestly, im on a project right now where actual "Architectural" decisions and details didnt get fully vetted and thought through (their models were linked INT and EXT). Now, im not saying that was a cause, because i wasnt there when it was detailed. But, the files are linked, their walls are overlap in goofy ways, and the details had the modeled stuff all hidden and faked, and it didnt work out in real life.

                    2. SaRang church wasnt a "mega tall," (images attached), but once you got above the bridge, the North and South tower Floors werent at the same height, so they were all different Levels. Yes, you are correct. It means manually checking the constraints on the wall tops. But, i very rarely am using level constraints for wall tops anyway, since not all walls go to deck. So its not exactly *more work* to go through and check the constraints.

                    In these scenarios where do you create your sheets? No matter what, you will have to tag through a link eventually, or use linked views.
                    Im not sure why this is said as absolution... "No Matter What." You dont NEED to tag through links. Or use Linked Views. But, you can. And yeah, thats a valid workflow. Ive done some large projects that way (both with tagging through the link, and with Linked Views). If i had to work with multiple files again, i would still use Linked Views. I *hate it less* than the tagging through the links, myself. But, if i had to work on a project with Links AND OTHER PEOPLE ON THE TEAM, i would tag through the links. I seem to be in the minority that doesnt mind switching files to work with Linked Views.
                    One issue is that large buildings often have views that span these multiple zones, complete with the need to reference views from these zones, which of course cannot be done through a link. All of this points towards wanting to keep all sheets together, unless you start to create duplicate views in each link in order to reference the overall views, which is error prone, or start creating dummy annotation tags.
                    This i dont understand, at all. Ive never needed dummy tags, even when working through Linked Views. If the Sheet needs an Overall Floor Plan (spanning multiple views) then all the files have an *Overall View* Plan in them, and they get their portions annotated there. And whichever file has the actual sheet, references the linked files Overall Views. Has worked fine for me (even in section/Elevation, since R9.1).
                    Is there a way to avoid walls and other elements (rooms, etc) from constraining themselves to the wrong level in a single building with multiple tower scenario? Is there a way to stop walls, columns and beams form joining up automatically by default, which then means things get moved by inexperienced staff? I have tried worksets, pinning an other methods, but short of manually remembering to disjoin things there does not seem to be a sure fire way to prevent these issues when modeling all in one file.
                    Already been said up above, but proper teaching > locking stuff.
                    Aaron "selfish AND petulant" Maller |P A R A L L A X T E A M | Practice Technology Implementation
                    @Web | @Twitter | @LinkedIn | @Email

                    Comment

                    Related Topics

                    Collapse

                    Working...
                    X