# Offset stored in IFC file, how and where?

**URL:** https://forums.buildingsmart.org/t/offset-stored-in-ifc-file-how-and-where/2848
**Category:** Users
**Created:** [July 14, 2020, 5:32pm UTC](https://forums.buildingsmart.org/t/offset-stored-in-ifc-file-how-and-where/2848 "2020-07-14T17:32:00Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![Hans\_Lammerts](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/hans_lammerts/32/835_2.png) [@Hans\_Lammerts](https://forums.buildingsmart.org/u/Hans_Lammerts)
#### Post date: [July 14, 2020, 5:32pm UTC](https://forums.buildingsmart.org/t/offset-stored-in-ifc-file-how-and-where/2848/1 "2020-07-14T17:32:00Z")

</div>

Many software have a value set ‘from origine’ to align exports and imports to a national grid (GIS use) This way, computing with big numbers is avoided. Using a local coordinate system 0,0,0

How and where are these values stored in the ifc format using an openbim workflow? What parameter should we be looking for for checking when we recieve models from other diciplines and parties? Thank you!

---

<div class="post-metadata">

### Author: ![nn1](https://avatars.discourse-cdn.com/v4/letter/n/ebca7d/32.png) [@nn1](https://forums.buildingsmart.org/u/nn1)
#### Post date: [July 14, 2020, 6:29pm UTC](https://forums.buildingsmart.org/t/offset-stored-in-ifc-file-how-and-where/2848/2 "2020-07-14T18:29:13Z")

</div>

Everything in IFC is positioned relatively (i.e. locally) back to a 0,0,0 of the IfcSite. This point is typically within or near the curtilage. Thereafter there can be a lat/long/elev or for a more formal approach there can be a IfcMapConversion to rotate,shift and scale relative to a [IfcProjectedCRS](https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC1/HTML/schema/ifcrepresentationresource/lexical/ifcprojectedcrs.htm) named mapping (EPSG) grid convention.

---

<div class="post-metadata">

### Author: ![nn1](https://avatars.discourse-cdn.com/v4/letter/n/ebca7d/32.png) [@nn1](https://forums.buildingsmart.org/u/nn1)
#### Post date: [July 14, 2020, 6:33pm UTC](https://forums.buildingsmart.org/t/offset-stored-in-ifc-file-how-and-where/2848/3 "2020-07-14T18:33:39Z")

</div>

There are several documents explaining geo-referencing here:

> **[Standards Library - buildingSMART International](https://www.buildingsmart.org/standards/bsi-standards/standards-library/#reports)**
>
> Standards Library buildingSMART International Standards buildingSMART Technical Reports buildingSMART Candidate Standards buildingSMART SPEC Publish buildingSMART Related Standards Around the World  buildingSMART White Papers buildingSMART...

---

<div class="post-metadata">

### Author: ![Hans\_Lammerts](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/hans_lammerts/32/835_2.png) [@Hans\_Lammerts](https://forums.buildingsmart.org/u/Hans_Lammerts)
#### Post date: [July 14, 2020, 7:46pm UTC](https://forums.buildingsmart.org/t/offset-stored-in-ifc-file-how-and-where/2848/4 "2020-07-14T19:46:55Z")

</div>

I am quite sure Lat Lon is NOT used in the domain of construction. In our country we use numerical values for XYZ positioning on _national grid_ (RD new Amersfoort). Can you be more specific how that can be used in IFC? Do i need to go through all these reports to find out?

Furthermore, it HAS to be a definition involving a point not a area or ‘curtilage’. I don’t really see how specifing some ‘area’ can be mm precise. Pllacement of a 3d object in space should be point related with a value for rotation indicating the xy axis (lat lon directions). An other way of aligning it to national grids is to have TWO point defining the position  
One for 0,0,0 and another one for some point on the grid. That is a ‘old skool’ cad method.

---

<div class="post-metadata">

### Author: ![nn1](https://avatars.discourse-cdn.com/v4/letter/n/ebca7d/32.png) [@nn1](https://forums.buildingsmart.org/u/nn1)
#### Post date: [July 14, 2020, 9:05pm UTC](https://forums.buildingsmart.org/t/offset-stored-in-ifc-file-how-and-where/2848/5 "2020-07-14T21:05:45Z")

</div>

I have described both the global positioning approach and the mapping grid approach and provided references to some very detailed documents. These cover the details for ifc2x3 and for ifc4x?

Sent whilst away from my desk.

---

<div class="post-metadata">

### Author: ![Hans\_Lammerts](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/hans_lammerts/32/835_2.png) [@Hans\_Lammerts](https://forums.buildingsmart.org/u/Hans_Lammerts)
#### Post date: [July 14, 2020, 9:50pm UTC](https://forums.buildingsmart.org/t/offset-stored-in-ifc-file-how-and-where/2848/6 "2020-07-14T21:50:56Z")

</div>

Ok. You described it.

---

<div class="post-metadata">

### Author: ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)
#### Post date: [July 14, 2020, 11:35pm UTC](https://forums.buildingsmart.org/t/offset-stored-in-ifc-file-how-and-where/2848/7 "2020-07-14T23:35:26Z")

</div>

@Hans_Lammerts a note that I have found issues in those published documents. Apart from some naming mistakes, which may result in incorrect geolocation in IFC2X3, more importantly the documents do not seem to fully describe proper usage when it comes to referencing EPSG registry identifiers. The practical result of this is that geolocation may be stored in misleading and inconsistent ways - remember that the easting / northing / vertical elevation numbers are merely half the storey: identifying the CRSes and projections used are equally important. Please read this thread for a full description of the issues, which are still outstanding half a year later.

> [@Geolocation standards in IFC2X3 and IFC4](https://forums.buildingsmart.org/t/geolocation-standards-in-ifc2x3-and-ifc4/2329):
>
> I have been working with @john.mitchell, co-founder of buildingSMART Australia, and a domain expert in map conversions and CRS entities in IFC to establish standards on how to geolocate projects in both IFC2X3 and IFC4. We have had a couple of informal discussions in person, so I thought to bring the discussion online so that others could see and contribute. Proposal 1 The first issue is that IFC2X3 does not have geolocation entities. To mitigate this, we propose an official convention that all…

If you are working with Revit users, this document by OSArch describing how to achieve geolocation in Revit may be useful:

[https://wiki.osarch.org/index.php?title=Revit\_geolocation](https://wiki.osarch.org/index.php?title=Revit_geolocation)

Even more detailed reading here (though Revit is mentioned, it talks about the general principles too):

> **[IFC Coordinate Reference Systems and Revit](https://thinkmoult.com/ifc-coordinate-reference-systems-and-revit.html)**
>
> BIM projects have to specify Coordinate Reference Systems and their relationship to surveyed points and project origins in order to reliably geolocate geometry. I describe how this works with IFC, and the current state of compatibility with Revit.

Now that the theory is out of the way, here are some practical realities to expect when in the trenches, at least in Australia - but it may be similar where you are:

1. The elephant in the room: if it’s coming from Revit, it’s probably wrong, hence the need to document the workarounds so rigorously in the links above
2. I’ve noticed that most civil BIM IFCs stick to absolute coordinates for everything. They do not record the geolocation offset. This can cause issues if your IFC program is not capable of offsetting it at import time. Note that there are open source tools to fix this and offset IFC files, if needed.
3. Unless you train people explicitly, do not expect IFC2X3 projects to be properly geolocated. Very few implementers respect the EPsets for geolocation.
4. Even though geolocation may be read by some BIM programs, do not expect it to properly feed through things like solar analysis or weather files.
5. The geolocation data (easting, northings, elevation) and the “reference” data (lat, long, elevation) and the address data are not connected: expect mistakes and inconsistencies.

---

<div class="post-metadata">

### Author: ![Hans\_Lammerts](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/hans_lammerts/32/835_2.png) [@Hans\_Lammerts](https://forums.buildingsmart.org/u/Hans_Lammerts)
#### Post date: [July 15, 2020, 6:16pm UTC](https://forums.buildingsmart.org/t/offset-stored-in-ifc-file-how-and-where/2848/8 "2020-07-15T18:16:06Z")

</div>

Why is this so complex. Ifc want me to think with all these parameters and methods it can be used in GIS software? Why?

The only thing i would need is the XY values of the offset. Just a text tag will do please.  
Hard to believe this is not being stored. Is this the case? Maybe our next ‘bim protocol’ EIR should say that users should use notepad and write in down manually in the header of ifc. Can this be a solution?

![xyz for local origine](https://us1.discourse-cdn.com/flex016/uploads/buildingsmart1/original/2X/b/b05a0ed62c3228a784f3820a8b43a7cb0dfa66b5.jpeg)

Image from Tekla. The lat lon is 0,0 because this is a method not to be used.

---

<div class="post-metadata">

### Author: ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)
#### Post date: [July 15, 2020, 10:19pm UTC](https://forums.buildingsmart.org/t/offset-stored-in-ifc-file-how-and-where/2848/9 "2020-07-15T22:19:11Z")

</div>

@Hans_Lammerts it is _not_ so complex. IFC lets you fill out the eastings, northings, and elevation as a text tag, and also nominate a coordinate system just like in your screenshot. Also, as you say, IFC discourages lat/longs, though it does let you nominate it for “convenience / reference only”.

The additional information you can record in IFC, also as a simple text tag, is an angle rotation, and a scale factor, both of which are required in the discipline. Also, it allows for you to go into detail on a coordinate system, which is required for custom coordinate systems used on complex jobs. That seems to be missing in your screenshot, but it in no way makes it complex in my opinion: just a few more text tags.

In Tekla, from memory (I am not experienced in Tekla), filling out that form will set the text tags necessary for a correctly geolocated IFC4 file.

The reason it seems so complex is because vendors have done a bad job implementing it, and perhaps correspondingly, the certification process either does not address this, or addresses it poorly (I do not know - the certification process is opaque).
