How is true north and magnetic north stored in IFC, and how does it interact with grid north?

Developers
1

Thanks to @jonm who brought this to my attention.

First: the easy one. In IFC4, grid north is defined through IfcProjectedCRS and IfcMapConversion, but specifically the north rotation (if a map conversion is used) is specified in IfcMapConversion.{XAxisAbscissa,XAxisOrdinate}. (Note: In IFC2X3, replace this with EPset_MapConversion on the IfcSite, with properties {XAxisAbscissa,XAxisOrdinate}). Awesome.

For true north, let’s consider some scenarios.

  • Scenario 1: IFC4, IfcProjectedCRS+IfcMapConversion is not present. Nothing else is defined. Proposed answer: grid, and true north are all undefined. Go fish.
  • Scenario 2: IFC4, IfcProjectedCRS+IfcMapConversionis present, nothing else is defined. Proposed answer: grid north is defined, but true north is undefined. Boo.
  • Scenario 3: IFC4, IfcProjectedCRS+IfcMapConversion is not present, IfcGeometricRepresentationContext.TrueNorth is present. Proposed answer: true north is defined, but grid north is undefined. Still boo. The big problem is that very often BIM applications don’t make this distinction, and users sometimes store grid north in the TrueNorth attribute. But this is a vendor error, not a problem with IFC. Edit: @lee.gregory has clarified that in this scenario, true north is meaningless, as it can only be read in conjunction with a specific geodetic datum, which needs to be specified with IfcProjectedCRS.
  • Scenario 4: IFC4, IfcProjectedCRS+IfcMapConversion is present, IfcGeometricRepresentationContext.TrueNorth is present. Proposed answer: grid north is present. True north is present.

Note: IFC2X3 is the same but replace IfcMapConversion with the pset.

Now, the devil in the details for scenario 4. My interpretation is that the rotation defined for grid north in IfcMapConversion and the rotation defined in TrueNorth are totally independent. In other words, they don’t stack. You don’t apply one, then apply the other. One simply points to grid north, the other points to true north. Both are relative to your project north.

My second interpretation is that in the same way that BIM authoring applications have a distinction between project north and grid north (i.e. you can potentially click a coordinate and survey it either in local or global coordinates), BIM authoring applications must also distinguish between project north and true north. In other words, they should not bake this transformation as part of the object placement transforms and hide it from the user. I don’t think any vendor actually bakes this, which is good, but I thought I’d mention it for completeness.

The issue comes in the wording in the documentation, which suggests that grid north can override true north, or, in other words, that they are dependent on one another. This seems incorrect as they are two different concepts. For example, this statement in the documentation:

NOTE If a geographic placement is provided using IfcMapConversion then the true north is for information only. In case of inconsistency, the value provided with IfcMapConversion shall take precedence.

Here’s another quote which seems incorrect (my commentary added in bold):

If a conversion to a geographic coordinate system is included by virtue of the HasCoordinateOperation attribute (this is IfcMapConversion, i.e. grid north), then the TrueNorth attribute shall be omitted or included only for informational purposes. It shall not be added to any transformation already applied by an IfcCoordinateOperation.

Am I the only one who is interpreting these sentences in the docs as suggesting that true north and grid north are being mixed up? I would’ve thought that these concepts are separate and one does not replace the other. If so, advice on how to reword the docs would be great.

Also, a bit of awkward inconvenience, that the MapConversion vector points in the X axis, and the TrueNorth vector points in the Y axis. Yikes. Is there a reason for this?

For magnetic north, no idea. Thoughts?

Edit, quote from @lee.gregory :slight_smile:

Magnetic North wanders all over the place and so is not used in mapping applications.

Nice.

Also, related reading on how WorldCoordinateSystem fits into all this confusion.

2

Dion,
The first question is what are you trying to achieve ?

There is no mention of an IfcProjectedCRS in the discussion.

In Scenario 1 and Scenario 3:

If there is an IfcProjectedCRS and no IfcMapConversion then the only sensible assumption is that the final coordinates in the IFC file are all the Easting and Northings of the Map Projection given in the IfcProjectedCRS.

Otherwise without additional information than what is contained in the IFC file, the data set could be anywhere. Well maybe not quite anywhere, if IfcGeometricRepresentationContext.TrueNorth is present then you are on a known great circle somewhere between the North and the South pole.

If there is no IfcProjectedCRS then from the IFC file alone, you have no idea where you are in the world. Even IfcGeometricRepresentationContext.TrueNorth is meaningless because that refers to a specific Geodetic Datum which is unknown as there is no IfcProjectedCRS .

3

@lee.gregory I should’ve mentioned IfcProjectedCRS, yes. My intention was (for simplicity’s sake in my scenarios) that both IfcProjectedCRS and IfcMapConversion were either both filled out or either both not present in the 4 scenarios.

I have edited my post.

The purpose is to confirm where true north is stored (as opposed to grid north) so that I know where the sun is, and to clarify why the sentences in the documentation seem to having conflicting information.

Your statements:

If there is an IfcProjectedCRS and no IfcMapConversion then the only sensible assumption is that the final coordinates in the IFC file are all the Easting and Northings of the Map Projection given in the IfcProjectedCRS .

Agree 100%.

Otherwise without additional information than what is contained in the IFC file, the data set could be anywhere. Well maybe not quite anywhere, if IfcGeometricRepresentationContext.TrueNorth is present then you are on a known great circle somewhere between the North and the South pole.

Also agree 100%.

If there is no IfcProjectedCRS then from the IFC file alone, you have no idea where you are in the world. Even IfcGeometricRepresentationContext.TrueNorth is meaningless because that refers to a specific Geodetic Datum which is unknown as there is no IfcProjectedCRS .

Ah, I see. I understand now. I will edit my original post to refer to this answer.

However, I still want to confirm my understanding of scenario 4. If both ProjectedCRS and MapConversion is present, can I confirm that the XAxisAbscissa/Ordinate are only relevant for grid north, not true north? And therefore, I need to inspect the value of IfcGeometricRepresentationContext.TrueNorth to determine where true north is?

If this is confirmed, can you also confirm that the quotes I have pulled out of the documentation need to be fixed?

4

Just had a chat with @lee.gregory and here is the unconfirmed conclusion so far. This post will be edited when this is confirmed.

In theory, it is possible to have an IFC file only with an IfcProjectedCRS and optionally an additional IfcMapConversion. This allows you to transform any local engineering coordinate into a map coordinate, with grid north pointing up. This map coordinate is in the CRS defined in IfcProjectedCRS.

From this CRS defined in IfcProjectedCRS, it is in theory possible for the computer to calculate a true north for an specified easting and northing. The specified easting and northing is likely to be the same origin at which you apply the IfcMapConversion.

This calculation is complex. It is likely unreasonable to expect many BIM stakeholders to be able to perform this calculation, and it is also likely unreasonable to expect many vendors to support this calculation.

Therefore, the quotes highlighted in the OP are technically accurate, but likely impractical. It may be desirable to store the true north rotation in all cases when an IfcMapConversion is present. (If the IfcMapConversion is not present, the specified easting and northing is ambiguous.

Right now, the current and only location in the schema available to store the true north is in IfcGeometricRepresentationContext.TrueNorth. This can remain as-is, however it is perhaps good to revise the wording in the documentation from its current recommendation to omit it in favour of the IfcMapConversion.

Edit: if the IfcProjectedCRS was a custom CRS defined for the project, then the calculation is likely impossible, as IFC does not store the full gamut of information required. Therefore, the field is required.

5

An additional minor issue which should probably be fixed. HasCoordinateOperation states:

If there is more then one IfcGeometricRepresentationContext provided to the IfcProject then all contexts shall have an identical instance of IfcCoordinateOperation as HasCoordinateOperation refering to the same instance of IfcCoordinateReferenceSystem.

The same restriction should be applied to TrueNorth. We can’t check instances, but we should at least mention the scenario.