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.
The first issue is that IFC2X3 does not have geolocation entities. To mitigate this, we propose an official convention that all
IfcProjectedCRS data must be recorded in a pset called
EPset_ProjectedCRS, and that all
IfcMapConversion data must be recorded in a pset called
EPset_MapConversion. These two psets must be associated with the relevant top level
IfcSite entity. The relationship between
IfcGeometricRepresentationContext and the geolocation that exists in IFC4 will be assumed but not explicit in IFC2X3 with this proposal. Similarly, the relationship between
IfcProjectedCRS will also be assumed. The attributes allowed are as follows:
PropertySet: EPset_ProjectedCRS I IfcSite Name Text EPset_ProjectedCRS.Name Description Text EPset_ProjectedCRS.Description GeodeticDatum Text EPset_ProjectedCRS.GeodeticDatum VerticalDatum Text EPset_ProjectedCRS.VerticalDatum MapProjection Text EPset_ProjectedCRS.MapProjection MapZone Text EPset_ProjectedCRS.MapZone MapUnit Text EPset_ProjectedCRS.MapUnit PropertySet: EPset_MapConversion I IfcSite Eastings Real EPset_MapConversion.Eastings Northings Real EPset_MapConversion.Northings OrthogonalHeight Real EPset_MapConversion.OrthogonalHeight XAxisAbscissa Real EPset_MapConversion.XAxisAbscissa XAxisOrdinate Real EPset_MapConversion.XAxisOrdinate Scale Real EPset_MapConversion.Scale
It is proposed that the existence of
IfcMapConversion / IfcProjectedCRS takes priority over the existence of these two psets. If the file is an IFC4 and the map conversion entities do not exist, but the psets do, then the psets may be parsed. However, this is not recommended.
I propose that when this is agreed upon, this IFC2X3 backport of the entities can be referred to in the documentation so that everybody can be aware of this convention. The final wording of this is not yet certain.
The second issue is that there is confusion over whether or not optional fields should be filled out in the
IfcProjectedCRS. To prevent confusion, we propose that if the
EPSG:### number provided in the
IfcProjectedCRS.Name field should match a code in the Official EPSG Registry, and therefore retrieve a WKT. To be more specific, in the GML export of the EPSG Registry, it must match the XPath
If the WKT is available and confers information equivalent to the optional attributes in the
IfcProjectedCRS entity, then these fields must be left blank in the IFC file. This prevents redundancy and potential mistakes in data copying.
These fields must only be filled out if the information is not present in the WKT.
This is already in the documentation, for example in sentences like the following
It needs to be provided, if the Name identifier does not unambiguously define the geodetic datum as well.
Therefore, I propose to modify the documentation to add similar sentences to all of the optional fields, as follows:
MapProjection: It needs to be provided, if the Name identifier does not unambiguously define the map projection as well and if the coordinate reference system is a 3D reference system.
MapZone: It needs to be provided, if the Name identifier does not unambiguously define the map zone as well and if the coordinate reference system is a 3D reference system.
MapUnit: It needs to be provided, if the Name identifier does not unambiguously define the map unit as well and if the coordinate reference system is a 3D reference system.
The third issue is that there is ambiguity around how to fill out other fields like the
The example given in the specification for
VerticalDatum are things like
EVRF2007 (note the documentation actually says
EVRS2007 - this is a spelling mistake and should be fixed). This corresponds to an XPath of
Similarly, an example given for
EUREF89, which again corresponds to an XPath of
/GeodeticDatum/metaDataProperty/CommonMetaData/alias. However, this is a good example as there are multiple aliases possible:
<epsg:alias code="7215" codeSpace="urn:ogc:def:naming-system:EPSG::7302" alias="ETRF89"/> <epsg:alias code="7216" codeSpace="urn:ogc:def:naming-system:EPSG::7301" alias="EUREF89"/>
Therefore, to prevent this ambiguity, I propose to establish a convention that the values must correspond to an XPath of
GeodeticDatum/identifier respectively. This has the advantage that there is only one possible value, so less room for mistake or ambiguity, and also that it is consistent with the XPath of
ProjectedCRS/identifier. Also, using an identifier is just good practice. Aliases are bad for data integrity in general.
The same argument applies to the
MapProjection attribute, which should link to an XPath of
OperationMethod/identifier. For example, the name “Gauss-Kruger” has multiple aliases, such as “TM” or “Gauss-Boaga”.
Therefore, the documentation examples should be changed as follows:
ED50 -> EPSG:6230 EUREF89 -> EPSG:1178 WSG84 -> EPSG:6326 (note: the original has a spelling mistake) DHHN92: the German 'Haupthöhennetz' -> EPSG:5181 EVRS2007; the European Vertical Reference System -> EPSG:5215 (note: the original has a spelling mistake) UTM -> EPSG:9824 Gaus-Krueger -> EPSG:9807
I additionally bring up the debate that WGS84, or EPSG:6326 is actually not a
GeodeticDatum in the EPSG registry, it is an
Ellipsoid instead. Perhaps this means that the IFC field could hold either the XPath
Also another side note “Gaus-Krueger” should be “Gauss-Kruger” - this spelling mistake should be fixed.
A practical example
A project in Sydney would have the following
Name: EPSG:28356 Description: NULL. Already provided in WKT, or XPath of ProjectedCRS/Name GeodeticDatum: NULL. Already provided in WKT or XPath of ProjectedCRS/baseGeodeticCRS VerticalDatum: EPSG:5111 (note: this is not provided in the WKT, so we have to specify it here) MapProjection: NULL. Already provided in the XPath, `ProjectedCRS/conversion/method` MapZone: NULL. Already provided in the XPath `ProjectedCRS/conversion` MapUnit: NULL. Already provided in the WKT.
Thoughts are welcome.