Revit, IFC and coordinate systems

Coordinate systems are certainly the most frequently asked question when it comes to Revit and IFC, so why is it so complicated?

Both Revit and IFC have their own ideas about coordinate systems and how to deal with local and world coordinates, which will be briefly introduced in this article.

Coordinate systems in Revit

Revit has 4 reference points, which are all superimposed on a new project in the standard template - we are talking about Revit Internal, Project Base Point, Survey Point and the Shared Site, whose origin is not visible but is displayed as a reference in the project base or survey point:

The local points (except Shared Site Origin) can be made visible in each view via Visibility / Graphics, as shown above.

There are different ways to work with these points, so here are a few personal best practices:

Internal Revit origin

This point is fixed and cannot be moved.

All model content must be within a 16 km / 10 mile radius or Revit will no longer be able to calculate and display the geometry correctly. Basically, this is not a problem, since such large structures are not edited in a single Revit project anyway. Problems only arise when content is linked that lies outside this radius (this often happens with CAD files from surveyors, for example).

Project Base Point

Defines the project coordinate system and is usually placed at a building corner or axis intersection. It can be moved, but if possible it should be left in its original position, as this simplifies other workflows (e.g. IFC export).

Survey Point

Usually placed at a known point on the building site, such as the intersection of property lines, and often serves as the common coordinate point for the surveyor.

The Survey Point can also be moved, either in the fixed or unfixed state, as it also references the Shared Coordinate System. The clip on the Survey Point symbolizes whether the survey point is currently fixed to or unfixed (detached) from the shared coordinate system:

  • Moving the unfixed / detached survey point moves the survey point to a new point on the site, independent of the shared coordinate system. Therefore, as soon as a shared coordinate system has been defined, the survey point should only be moved when unfixed!
  • Moving the fixed Survey Point also moves the coordinate system at the same time and should only be done after consultation with other project participants!

Shared coordinates

Used to share the same coordinate system between different project files and/or systems - these can be local coordinate systems or GIS coordinate systems, allowing the project to be located in relation to a world coordinate system.

Again, there are different ways to enter GIS coordinates in Revit: under Manage, the coordinates can either be obtained from a file (Acquire Coordinates) or specified at a point (Specify Coordinates at Point).

The best way is to retrieve the coordinates from an already correctly located DWG, e.g. the survey plan, as this also transmits the correct coordinate system:

After setting the shared coordinate system, the corresponding coordinates are reported back on the project base point as well as the survey point:

Altitude/rotation handling

As can be seen in the last screenshot, the rotation between project north and geographic north, as well as the height (e.g. above sea level) can also be specified. The height is entered directly in the unfixed survey point, whereby both the project base point and the fixed survey point can then be moved again in space. It is important to know that the actual height offset between the internal origin and the selected reference point is relevant for the IFC export - this is clearly visible in a section or a side view, for example.

Project North rotation is well documented in the Revit Help: Help | Rotate Project North | Autodesk

IFC export settings

What happens now during the IFC export and what is the purpose of the long introduction? When exporting IFC, all selected reference points can be selected as the origin - in addition, the internal origin as well as the project base point can even be selected with project or true north, which can lead to confusion.

There is a common misconception that the GIS coordinates are only exporting with the "Shared coordinates" option and are therefore the best setting, which is not true. The information about the GIS coordinate system is carried along in the background in the IFC file, similar to the way it virtually exists in Revit and is used to calculate the shared coordinates of the project or survey point. At this point, the difference between BIM and GIS systems becomes clear:

  • A GIS system is designed for horizontal structures and therefore works with GIS coordinates to be able to handle distances and deviations based on the curvature of the earth
  • A BIM system is designed for vertical structures (buildings) and works with a local project coordinate system, since any deviations due to the curvature of the earth are negligible. The project base point only carries the information about its location in the GIS system, so that the building knows where it is on the globe.

The IFC schema supports both approaches and, especially since IFC4, offers a very simple way of passing on both the local project base point of the BIM project and the GIS system - in Revit the corresponding information is displayed in the export settings:

This means that the reference point selected during export does not decide whether GIS coordinates are exported or not - it only defines the local coordinate system to which the building is aligned.

What is the difference between the individual reference points, after all there are 6 options available in Revit:

Basically, the model content is exported based on the location of the origin selected during export. To illustrate this, I'll overlay the export results of my test file, which looks like this:

The result im BIMcollab Zoom (Top View) looks like this:

What does that mean now?

The Project Base Point, i.e. the "official" zero point of the Revit model, is mapped to the zero point of the IFC Viewer - regardless of which export method is used. When exporting based on the survey point or the internal Revit origin, these will also keep their offset from the Project Base Point.

The Shared Coordinates option is a special case - this is actually only recommended for a local shared location, but not when using the GIS coordinates. When exporting, Revit indicates this and recommends choosing a different reference point:

If you chose to use this option, you must be aware that the result might be displayed differently depending on the recipient: some IFC Viewers do not show the result at all (e.g. Open IFC Viewer), while others (BIM Collab Zoom) place the model content close to its own origin.

Conclusion / Recommendations

LOCAL BASE POINT: A local origin should always be used for the export of BIM projects to IFC (ideally the Project Base Point or Survey Point / Internal Origin in Revit). This point should also be known to the other trades and, if possible, also used for their IFC export.

COORDINATION MARKERS: It is recommended to always place coordination markers (typically inverted pyramids) at the coordination point(s) in all authoring solutions and also include them in the IFC export. They can serve as a visual check and alignment.

REFERENCE IFC FILES IN REVIT. If IFC files are linked in Revit, the link is always "Origin to Origin", ie the origin selected during export is mapped to the internal Revit origin (for this reason the recommendation to leave the Project Base Point on the Internal Origin).

UNDERSTANDING GEOREFERENCE: The georeferencing is embedded in IFC4 and should not serve as the source of coordination in BIM projects, but provides additional information for embedding in GIS systems.

More recommendations on BIM coordination can also be found in the official modeling guide: modeling_guide_v1.1.pdf (

  1. Thank you Lejla for the detailed contribution to a truly complex topic. We also have many support requests regarding this topic. What is still not entirely clear to me is why IFC are read in with an additional rotation when the project north is rotated. In a workflow without a DWG, this means that an IFC is read in once to match the coordinates. If the IFC is read in again afterwards, it appears in a rotated position. In the further exchange, all models then agree.

    1. Thank you, Fabian! Yes, that's a bit tricky - I think it has to do with Revit Internal not taking rotation into account. In my experience, IFCs exported with True North are also referenced correctly - the only problem is those exported from eg Revit without True North, right?
      I'll have to test and document this again, good point!

      1. Hello Lejla, the other way around. The True North doubles because it is set once in Revit and then comes in again with the IFC. When importing with IFC aligned to the project north, the rotation is carried out correctly and only once. LG Elke

  2. Hello Lejla, this is by far the best article I have read in the German-speaking world in the area of ​​Revit, IFC and coordinate systems. I was already familiar with the topic from my own experience, but this article helped a lot to create a common understanding among different user groups.

    1. Thank you very much for the comment! It is indeed a complex topic and I would be happy if my contribution makes it a little easier! 🙂

  3. Hello Lejla,
    First, thank you for this accurate article. Second, I'm sorry about my poor English. Third, I have a little bug in Revit 2024 (not 2023) and maybe you can help me (and us) :
    When I import a georeferenced IFC model in Revit 2024 (IFC4, or IFC2x3), some object like IfcOpeningElement appear far, near the 0,0,0 point, and the rest of the building appear at the shared coordinates = same Internal origin, Project , survey point.
    So Revit model is too large and displayed wrong.
    Have you ever heard about this problem?
    The only solution I've found it's to modify the coordinates in IFC text file to 0,0,0 :
    Thanks a lot for your precious help and have fun

  4. Hi Christophe, are you using the latest update (2024.2)? If yes and this still happens, most probably it's related to the way your file and the IFC export are set up – the best is if you open a support case and attach the Revit file, so our colleagues can have a look at it and tell you more. Thank you!

    1. Hi Lejla,
      Thank you for reply. Yes I've got the latest updates of Revit 2024 and IFC plugin.
      It's strange problem because I have it on 2 different computers and a coworker has different result: all objects are at the good place but some missing.
      Like you say it's probably set up or Archicad IFC export settings problem.
      I'll not disturb you anymore, I'll just write to you if I find something concrete.
      Thank you very much, bye bye.

  5. Hi Lejla,
    This will be a newbie question, sorry.
    In our company, we never set up a coordinate system ourselves for others to follow as we use the architects files as the lead consultant in all projects.
    Our typical workflow is to link the architects model into our project and acquire their coordinates and model from there. All other consultants models are linked with this coordinate system. This seems to have worked well with no complaints about incorrect location of our model. I'm still getting my head around Revit's coordinate system but wanted to check that our approach was the best way to ensure correct locations for coordination on every project.
    One modeller from a different company has had the workflow of just linking the Architects model via “Auto – Center to Center” and modelling his services to suit that positioning.

    Can you point me in the right direction as most online explanations generally discuss how to set up the coordinate system from scratch not the best method of working with someone elses coordinates seamlessly.
    We work in all versions of Revit from 2019 to 2024 at this point depending on the lead consultants model.
    Any help or clarification would really be appreciated. Thank you

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment is processed.

Previous Article

Export Revit phases to IFC

Next Article

Construction phases in IFC - status and tasks