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 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 IfcMapConversion and 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.
Proposal 2
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 ProjectedCRS/identifier.
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.
Proposal 3
The third issue is that there is ambiguity around how to fill out other fields like the VerticalDatum or GeodeticDatum.
The example given in the specification for VerticalDatum are things like DHHN92 or EVRF2007 (note the documentation actually says EVRS2007 - this is a spelling mistake and should be fixed). This corresponds to an XPath of /VerticalDatum/metaDataProperty/CommonMetaData/alias.
Similarly, an example given for GeodeticDatum is 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 VerticalDatum/identifier and 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 GeodeticDatum/identifier or Ellipsoid/identifier.
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 IfcProjectedCRS attributes:
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.
@jwouellette - I hope that if @john.mitchell and others agree on these proposals, they can make their way into the documentation. The schema does not change in any of these proposals.
