No announcement yet.

Understanding of the Revit Project Origin - Looking for Peer Review Comments

  • Filter
  • Time
  • Show
Clear All
new posts

    Understanding of the Revit Project Origin - Looking for Peer Review Comments

    Hello everyone, I've struggled with this topic in Revit for quite a while.
    I teach professionally, and have had trouble explaining this topic clearly and succinctly so far. I've managed to put together all my thoughts on the subject and what I think should be a best practice when setting up a Revit Project in a blog post is here: TechLog: Keeping Revit Origins Sane in the Real World

    I would really appreciate it if anyone could tell me if it makes sense and how I could improve on it.

    Good post overall. It is always good to see different methods of explaining the base points :thumbsup:

    I'm guessing you've seen Paul Aubin's course on Shared Coordinates as well as Steve Stafford's? If not they are both worth a look and explain it a little differently.
    Revit for newbies - A starting point for RFO

    BEER: Better, Efficient, Elegant, Repeatable.


      Thank you for responding Cellophane. I did turn over Steve's and Paul's excellent explanation for a while. I think they have done a better job of explaining how the Revit Coordinate System is set up. My goal is to derive a saner way to use (or more specifically: not use) the Shared Coordinate System of Revit.

      I always find myself at a loss to explain/rationalize a situation once a Project and its links no longer seem to want to share a common location (My guess is that the Named Location was inadvertently overwritten - something that seems to happen surprisingly often).

      More importantly, I would like to know how to rectify a situation once the Shared Coordinates have broken down. So I am proposing that one should not use Shared Coordinates (Named Locations) unless a link is repeated in multiple locations within the same Project (in which case it is unavoidable).
      Secondly, it is worthwhile to place a Model marker at the Revit's Relative Origin (WCS 0,0,0) within each individual link and the Parent Project so that if something bad were to happen, one can always re-position project based on the markers both within Revit or within a secondary application such as Navisworks/Synchro/Solibiri. A prerequisite for this would be that the Relative Origin of the file should be worked out even before modeling has begun.

      So my question really is if this approach is logically sound given the complexities of large projects and multiple links/consultants?


        Some generalizations...
        • The larger the project team the fewer people should have anything to do with shared coordinates. It is not a feature that everyone should feel they are entitled to touch regardless of how well they understand it. Once it is configured, everyone should leave it alone.
        • Revit to Revit model relationships should be based on Origin to Origin - it does not require shared coordinates at all
        • Architect shares model with trades and they model inside the building.
        • Shared Coordinates only needs to be engaged when there is an expectation that Revit models will align with other 3D data in other software that uses an alternate coordinate a survey...and they don't already align based on their own origins. For example, all the Revit models will already align in Navisworks without shared coordinates but they probably won't align with a piping or HVAC model created with other software.
        • The architect creates a shared coordinate relationship between their model and a survey/site source. Trade's models inherit this relationship from their copy of the architects model via Acquire Coordinates. Revit models remain shared via Origin to Origin, that remains unchanged. Don't remove trade models and link again via Shared Coordinates. If there are multiple architectural models then one should be regarded and used as the master for trades to use for Acquire Coordinates.

        Fwiw, I don't think your article reaches the conclusions or goals you set for yourself yet. It does describe facts about shared coordinates but does not quite reach providing clear guidance; one of your stated goals. For example, you delve into the subtlety of moving a Project Base Point un-clipped and how that might be useful. You might find it interesting that in my travels I've found very few people find it compelling. Perhaps they are a bit too removed from construction themselves to appreciate it more? By comparison you don't deal with the fundamental reason I find people do use it, survey/site relationships...with as much detail.

        Regardless, writing to express our own understanding of complex ideas and concepts to share with others is well worth the effort. Cheers!


          Thank you Steve. I appreciate your reply very much. I've gone ahead and expanded on the post a bit more to include some more of the functions of the tool-set and my summary on what the best practices should be.
          Particularly, I am curious about your opinion on the idea of placing a 3D marker on the site of the Relative origin as a way of tracking its location and potentially using it as an alignment marker if something were to go wrong.


            Originally posted by para_analytics
            ...I am curious about your opinion on the idea of placing a 3D marker on the site of the Relative origin as a way of tracking its location and potentially using it as an alignment marker if something were to go wrong...
            Yes, it is a good idea and habit to develop. Not necessarily at the actual site origin though as that can be quite far away. It works just as well if it is at specific coordinates relative to the site origin or benchmark, but much closer to the project (building(s)) itself.
            Last edited by Steve_Stafford; November 3, 2016, 11:19 PM.


            Related Topics