IfcSite does not reference the EPSG code for WGS84 and further inconsistencies with georef

Developers
1

The IfcSite documentation states WGS84, but since there are many WGS84s out there, we need to clarify which one.

World Latitude at reference point (most likely defined in legal description). Defined as integer values for degrees, minutes, seconds, and, optionally, millionths of seconds with respect to the world geodetic system WGS84.

World Longitude at reference point (most likely defined in legal description). Defined as integer values for degrees, minutes, seconds, and, optionally, millionths of seconds with respect to the world geodetic system WGS84.

I am not a domain expert, therefore I would assume it is EPSG:4326. However, I could be totally wrong :slight_smile:

A further issue is that this RefLatitude and RefLongitude actually are based on the IfcSite.ObjectPlacement, whereas the IfcMapConversion, if it exists, is based on the origin. This inconsistency can only serve to create confusion and possible errors.

Also, is it irking anybody else that all this geolocation related stuff is spread around so many entities in the IFC spec? Can’t it all be put in one spot? Can this be fixed for IFC5?

2

In addition, the only mentions of resolving to map coordinates in the project local placement docs is:

at the outermost level, a site is globally positioned according to latitude, longitude, and elevation;

This is kinda highly misleading. Can we please reword this to describe how we should instead apply the map conversion? These lat/long/elevation (and the true north rotation which is in a totally different location) are only for reference.

1 Like
3

I recall reading clarification documents on bSI Australia chapter website some time ago, maybe that could be of help.

4

Cheers @claimred - most of the issues you’ve noticed me posting recently have been after consultation with @lee.gregory and @john.mitchell . In fact, @lee.gregory, who I believe is one of the authors of that very document, is who spotted this issue :slight_smile:

Also fun is that the document even recognises the issue:

An example of a dynamic datum is the one used for GPS which is referred to as WGS84. Unfortunately this is the same name as the name given to the ellipsoid the datum uses so one has to be careful what is being referred to when just WGS84 is mentioned.

Should be an easy fix … ping @john.mitchell ?

1 Like
5

Wgs84 define an ellipsoid and center, so there is only one unique worldwide system here.
EPSG for wgs84 is EPSG4326

6

From what I understand, yes, but @lee.gregory said he wanted to double check this, and he’s a domain expert :slight_smile:

These points still apply:

7

Yes WGS84 does define the ellipsoid.
However that is NOT enough to define the Longitude and Latitude for a point.

You also need the epoch (time) for WGS84 that the longitude and latitude refers to.
As far as I know there are now seven different epochs for WGS84.

In Australia, the difference in the position for the same longitude and latitude from the 1994 WGS84 epoch to the 2020 WGS84 epoch is about 1.8 metres.

2 Likes