Offset stored in IFC file, how and where?

Users
1

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!

2

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 named mapping (EPSG) grid convention.

3

There are several documents explaining geo-referencing here:

4

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.

5

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.

6

Ok. You described it.

7

@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.

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

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

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.
1 Like
8

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

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

1 Like
9

@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).

2 Likes