buildingSMART Forums

Geolocation standards in IFC2X3 and IFC4

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.

Dion and colleagues

an important correction: the details of Geolocation were started by Norway and in the MSI project several key players from the UK, Denmark, Germany, Finland and Australia were responsible for putting the technical details together, not me.

Secondly, Jon Proctor of BSI has just finished documenting a final version of our documents of the MSI project and has passed them to the Building Room for review and thence official publication.

Dion has well described the need for unambiguous implementation of MSI and I encourage vendors now to contribute to these final discussions.

1 Like

Thanks @john.mitchell - I have modified my flattering introduction of you :slight_smile:

I have also edited my post to mention more spelling mistakes as well as to talk about the MapProjection attribute, which was previously also ambiguous. I have also added a practical case study to show what a final result would look like if all of these proposals were followed.

@john.mitchell - can you ask Jon Proctor to look over my post above to see what his thoughts are? Especially in regards to biggest change I am proposing: to use identifiers rather than aliases - this makes things much simpler and less ambiguous.

It would also be good if Jon Proctor could post here so that the community could see his work submitted to the Building Room and perhaps add their thoughts.

Perhaps the documentation could also reference XPaths in the EPSG Registry GML as I have deciphered above. This would allow vendors to automate the detection and conversions of these fields. Currently, no mapping to the EPSG registry is mentioned and therefore data is left to human interpretation.

One more thing to keep in mind: over the lifetime of a building, it moves around relative to WGS84 due to plate tectonics. Are local GeodeticDatums to be preferred over global ones? Or do we trust readers to look at the date stamp?

Although you make a good point, I do not believe it is the responsibility of the schema to specify what datum is more appropriate. That would be a decision made by the qualified surveyor or engineers on the project.

1 Like

I don’t see the reason to support the psets in IFC4, they just complicate matters. I think they should only be used for IFC2X3.

The fields in IfcProjectedCRS are not themselves enough to define the coordinate system since they don’t provide the parameters of the projection, ellipsoid etc. As such I think it is fine to leave them blank if an EPSG record provides that information.

Note that WGS84 is both an ellipsoid and a datum. I.e. the name refers to two different things (though they are normally used together). Also note that WGS84 (the datum) is dynamic and is updated from time to time. The two things should not be combined. I could not find EPSG:7030.

I don’t understand your XPaths. What is ‘ProjectedCRS/conversion/method’?

1 Like

@bron There is no reason to support the psets in IFC4. However, from experience, vendors share a lot of parsing code between IFC2X3 and IFC4 implementations. Therefore, it would be prudent to specify what takes priority. This is in line with current IFC documentation about how RefLatitude can be specified, but MapConversion takes priority.

Correct, if the IfcProjectedCRS is an EPSG record, then the data may well be insufficient. That will be addressed and solved in the WKT extension. However, that is not the focus of this thread. This thread is to do with data formatting within existing schema attributes, not proposing to add or change the schema.

Thanks for clarifying the ellipsoid and datum status of WGS84. EPSG:7030 is the Ellipsoid code, and can be found here by doing “retrieve by code” and searching for “7030”. Therefore, it should be the datum, therefore, EPSG:7030 is wrong and should be EPSG:6326, I believe, but I would appreciate if you could confirm this. I will edit my post.

The XPaths are how to navigate to the identifiers using the GmlDictionary.xml format provided by the EPSG registry. I simplified it a little bit in my post - in reality it would contain some attribute predicates.

@Moult I was not suggesting about changing the schema, only noting that it is not currently able to define the type and parameters of a projection.

I think you are right, EPSG:6326 is the WGS84 datum. You can see in the “Anchor Definition” that it has changed over time as it has been updated for tectonic changes.

Thanks for explaining about the XPaths. I was not familiar with the GmlDictionary and rarely use the EPSG registry.

Correct. My post largely deals with identified EPSG CRSes. I think we are both in agreement that the current schema is has a few more fundamental issues. Although I am not a domain expert, I believe it could be improved with the introduction of a WKT extension to the schema - but that is for another thread to discuss :slight_smile:

I have edited my post to change 7030 to 6326.

The XPath definition (or similar programmatically located definition) is vital to ensure that everybody unambiguously arrives at the exact same naming scheme for EPSG codes.

Hi Jon Proctor here, responding to the comments above. As John Mitchell states, a version 2 of the User Guide for Geo-referencing in IFC (previously known as IDM Model Set Up) has been finalised recently and is available on the bSI sharefile in the Building Room Folder within the Useful Information for Members section.

It is also in the process of being published as a technical report on the bSI website.
Please do review the content and leave feedback here. The User Guide consists of the following documents:

  1. Executive Summary
  2. User Guide for Geo-referencing in IFC
  3. Appendix A: Demonstration Scenario for Model Setup IDM
  4. Appendix B: Geo-referencing BIM
  5. Appendix C: Process Model
  6. Appendix D: MSI Exchange Requirements

Special thanks go to John and his team of technical experts for their time and dedication to this project and in developing the User Guide.

1 Like

here is the link for the User Guide and associated documents on the bSI sharefile:

https://buildingsmart.sharefile.com/home/shared/fo81a169-527f-4832-a683-6117aadf69e2

Dear @JonProctor just those who have permission to access to the folder or a specific project can see it

I think it’d be better you share a public folder that all can see it without having an account and specific permission to the specific project or folder

2 Likes

@JonProctor - @ReD_CoDE is correct. can you please reshare the link in a publicly accessible manner? Otherwise the community is unable to provide feedback.

I’ll post the link to the web site when we have the reported loaded so that all can access it.
regards

Jon

The User Guide for Geo-referencing in IFC has now been published as a Technical Report on the buildingSMART.org website. The link to access the report and its appendices is:

Alternatively, from the buildingSMART.org home page, select the Standards menu and from there select Standards and Standards Library. The User Guide and its appendices are listed on this page in the Technical Reports section.

Enjoy.

A reminder of the various elements of the User Guide:

  1. Executive Summary
  2. User Guide for Geo-referencing in IFC
  3. Appendix A: Demonstration Scenario for Model Setup IDM
  4. Appendix B: Geo-referencing BIM
  5. Appendix C: Process Model
  6. Appendix D: MSI Exchange Requirements
2 Likes

Thanks for publishing the guide. I haven’t read through in detail, but after a quick skim I see a few issues that might need to be corrected:

  • The psets in IFC2X3 are nominated as ePSet_.... This creates an inconsistency in naming. I propose to rename it either to ePset_... or EPset_.... The S is not capitalised in all other pset names.
  • Page 14 misses out some of the properties in table 2 for projected CRS. Also typo for IfcGrid.
  • Page 15 of the user guide does not clarify exactly how the name is taken from the EPSG list. The screenshot shows the value EPSG:28356, which is good, but it is ambiguous as to exactly how it is derived from the EPSG list. My proposal in this thread about specifying the XPath can clarify this.
  • Again, Page 15 shows a description value in the screenshot. Should this not be derived from the EPSG registry? Why is it seemingly set to a custom arbitrary value here?
  • Again, Page 15 seems to show the exact same value in the MapProjection field as well as in the Name field. This seems incorrect. See the XPath clarification in the post above.
  • To prevent repetition, the user guide seems to miss out on the three proposals in this thread, which still seem to be unresolved issues. It would be good to integrate these 3 proposals into the user guide.

If somebody were able to point at the correct Git location to create a pull request, I would be able to help integrate these changes into the official IFC documentation.

@john.mitchell - I would be happy to clarify these points in person if need be.

2 Likes