# How is true north and magnetic north stored in IFC, and how does it interact with grid north? **URL:** \ **Category:** Developers\ **Created:** [March 30, 2021, 6:57am UTC](https://forums.buildingsmart.org/t/how-is-true-north-and-magnetic-north-stored-in-ifc-and-how-does-it-interact-with-grid-north/3491 "2021-03-30T06:57:15Z")\ **Posts on this page:** 5\ **Page:** 1
**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:** [March 30, 2021, 6:57am UTC](https://forums.buildingsmart.org/t/how-is-true-north-and-magnetic-north-stored-in-ifc-and-how-does-it-interact-with-grid-north/3491/1 "2021-03-30T06:57:15Z")
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`+`IfcMapConversion`is 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](http://localhost:8001/schema/ifcrepresentationresource/lexical/ifcmapconversion.htm) then the true north is for information only. In case of inconsistency, the value provided with [IfcMapConversion](http://localhost:8001/schema/ifcrepresentationresource/lexical/ifcmapconversion.htm) 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](http://localhost:8001/schema/ifcrepresentationresource/lexical/ifccoordinateoperation.htm). 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 🙂 > Magnetic North wanders all over the place and so is not used in mapping applications. Nice. Also, [related reading](https://forums.buildingsmart.org/t/can-worldcoordinatesystem-be-removed/3492) on how WorldCoordinateSystem fits into all this confusion. ---
**Author:** ![lee.gregory](https://avatars.discourse-cdn.com/v4/letter/l/eb9ed0/32.png) [@lee.gregory](https://forums.buildingsmart.org/u/lee.gregory)\ **Post date:** [March 31, 2021, 4:01am UTC](https://forums.buildingsmart.org/t/how-is-true-north-and-magnetic-north-stored-in-ifc-and-how-does-it-interact-with-grid-north/3491/2 "2021-03-31T04:01:19Z")
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**. ---
**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:** [March 31, 2021, 4:17am UTC](https://forums.buildingsmart.org/t/how-is-true-north-and-magnetic-north-stored-in-ifc-and-how-does-it-interact-with-grid-north/3491/3 "2021-03-31T04:17:29Z")
@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? ---
**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:** [April 1, 2021, 6:28am UTC](https://forums.buildingsmart.org/t/how-is-true-north-and-magnetic-north-stored-in-ifc-and-how-does-it-interact-with-grid-north/3491/4 "2021-04-01T06:28:25Z")
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. ---
**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:** [April 3, 2021, 10:13am UTC](https://forums.buildingsmart.org/t/how-is-true-north-and-magnetic-north-stored-in-ifc-and-how-does-it-interact-with-grid-north/3491/5 "2021-04-03T10:13:43Z")
An additional minor issue which should probably be fixed. `HasCoordinateOperation` states: > If there is more then one IfcGeometricRepresentationContext provided to the [IfcProject](http://localhost:8001/schema/ifckernel/lexical/ifcproject.htm) then all contexts shall have an identical instance of [IfcCoordinateOperation](http://localhost:8001/schema/ifcrepresentationresource/lexical/ifccoordinateoperation.htm) as _HasCoordinateOperation_ refering to the same instance of [IfcCoordinateReferenceSystem](http://localhost:8001/schema/ifcrepresentationresource/lexical/ifccoordinatereferencesystem.htm). The same restriction should be applied to `TrueNorth`. We can’t check instances, but we should at least mention the scenario.