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

[Moult]

Originally https://forums.buildingsmart.org/t/ifcsite-does-not-reference-the-epsg-code-for-wgs84-and-further-inconsistencies-with-georef/3499

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 :)

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?

[berlotti]

Proposal to deprecate lat/lon. Ping @TLiebich

[Moult]

Agreed that lat/lon no longer has any meaning after there are potentially multiple MapConversions, and also that IfcSite may not necessarily have an object placement at 0,0,0 which means that users almost always get this value wrong.

However, many sustainability tools depend on lat longs for simple weather data, solar compass orientation, and we cannot expect every IFC viewer or sustainability tool to come with a GIS reprojection / coordinate conversion toolkit or EPSG lookups.

Would it be a bad idea to add Lat Longs purely as an optional reference value into IfcMapConversion?

[Moult]

Ping @LeeGregory12d

[SergejMuhic]

Agreed that lat/lon no longer has any meaning after there are potentially multiple MapConversions, and also that IfcSite may not necessarily have an object placement at 0,0,0 which means that users almost always get this value wrong.

However, many sustainability tools depend on lat longs for simple weather data, solar compass orientation, and we cannot expect every IFC viewer or sustainability tool to come with a GIS reprojection / coordinate conversion toolkit or EPSG lookups.

Would it be a bad idea to add Lat Longs purely as an optional reference value into IfcMapConversion?

For that purpose, I would prefer to have a pset.

Also, IFC Tunnel will propose a rework that will feature geographic/geodetic (still working out the correct naming with the experts) coordinate systems.

[SergejMuhic]

Also pinging @pjanck

[TLiebich]

a historic summary first:

• when the lon/lat/height had been added to IFC (remember somewhere in the time frame of IFC2x (around 2000) the only! use case was to support applications to carry out solar or shading simulations. At that time, log/lat war degree/min/sec with no fractions of seconds
• in IFC2x3 time frame the demand was extended to a use case to be able to (roughly...) position buildings on e.g. a Google Earth application, so that the fraction of seconds got added (as a quick & dirty solution). No requirement of proper geo referencing yet.
• this came up in IFC4 time frame and let to the addition of IfcMapConversion + friends (still mainly driven from the building world)
• in IFC4.x time frame and the need for proper support of geographic coordinates, deficiencies in IfcMapConversion + friends were identified (and improvements suggested) plus the awareness that the "old" IfcSite lat/lon/height + true north are now redundent (when the IfcMapConversion is property handled, which not all use cases in the building sector demand)

having said all this - in my view and analogy, we now have a proper way to handle geographic coordinates (maybe with more to come from tunneling) - this is the default and geometricly precise way (and always takes predecends)

Still for buildings there is the need for some "business" concepts, adding the lon/lat as WGS84 for easy use in UC/applications without the request to handle ESPG/etc. Here, as als @SergejMuhic hinted, the best way would be:

• deprecate the direct attributes lon/lat/heigth + true north
• add those as property set to IfcSite (e.g. as a new PSet_SiteWGSLocation)
• for lon/lat change data type from degree/min/sec to decimal degree (e.g. REAL)
• for this purpose, the exact ESPG code, etc. is not relevant (a diff of 1 meter or so does not influence solar calculations)
• add to documentation, that this pset is not suitable for positioning (here use only IfcMapConversion), but for informal purposes only.

[Moult]

Agree with everything.

IfcSite may not necessarily have an object placement at 0,0,0 which means that users almost always get this value wrong.

Rethinking this, this is both good and bad. For a project working in map grid coordinates, it is now their responsibility to properly place the IfcSite in a logical position. I've seen a lot of scenarios where the IfcSite, IfcBuilding is a 0,0,0 and the IfcPipeSegment or whatever civil thing is off at 334917,6734982,25 (made up huge number). We need to make it clear that the lat longs refer to the "converted" location of the IfcSite. That way also if a project has multiple sites (on a huge military base, which I've experienced), you just need to find your closest site parent in the spatial hierarchy and look up its lat longs.

I also propose to deprecate RefElevation on IfcSite since it has the same logic as lat/long. And propose to add RefElevation to the new Pset_SiteWGSLocation.

Can I also add to the proposal to deprecate TrueNorth in IfcGeometricRepresentationContext which is yet another "meaningless" (in the context of multiple IfcSites) value and also another "reference" value that has a similar purpose for solar and weather studies. Then, I propose to add TrueNorth to this Pset_SiteWGSLocation?

The end result is all the precise geolocation lives in MapConversion/ProjectedCRS, and all the reference, less precise, "sampled" (i.e. only valid at a particular easting/northing) coordinates for solar / weather lives in Pset_SiteWGSLocation? Only two spots, instead of spread around with ambiguities on exactly which spot they reference.

[TLiebich]

+2 from my side ;-)

[Moult]

Ugh sorry I completely misread @TLiebich you also did propose height / true north so ignore my post we are in agreement :)

Note we still haven't actually solved the initial issue of this bugreport ... what is the EPSG code of WGS84?

Also, can I propose we deprecate IfcGeometricRepresentationContext.WorldCoordinateSystem? If find it completely unnecessary now and adds confusion to actual geolocation.

Meanwhile, here is a more detailed proposal:

• Deprecate IfcSite.RefLatitude, IfcSite.RefLongitude, IfcSite.RefElevation, IfcGeometricRepresentationContext.TrueNorth
• Purge docs for IfcGeometricRepresentationContext and IfcSite which refer to those now deprecated entities
• Delete (or better, redo this diagram) on IfcGeometricRepresentationContext because showing true north is now invalid, and its useful to have a diagram which shows clearly +Y as project north and the rotation after the map conversion.

• New Pset called "Pset_WGSLocation" applicable to IfcSite (I removed "Site" from the name because in theory it could be applicable to anything... IfcBridge, or whatever?)
• Add following properties:

 - TrueNorth
 - REAL? Maybe?
Direction of the true north, or geographic northing direction,  relative to the
underlying project coordinate system. It is given by an ... ??? .... If not
present, it defaults to 0. 1., meaning that the positive Y  axis of the project
coordinate system equals the geographic northing  direction. NOTE  If a
geographic placement is provided using IfcMapConversion then the true north is
for information only. In case of inconsistency, the value provided with
IfcMapConversion shall take precedence.

 - RefLatitude, RefLongitude, RefElevation change to REAL and descriptions copy pasted, but the example needs to be edited to use decimal degrees.

For true north, should the data type change to REAL and be defined as... say an angle of counterclockwise rotation from project north +Y to true north? This will match the diagram previously used for true north. Like this:

[Moult]

A note that this will also solve #315

[Moult]

I would love to get this one in and finally (or at least, much closer to finally) wrap up a lot of geolocation confusion - upgrading to proposal since it's almost there.

This would also solve #317.

[ccast1]

to be checked by @SergejMuhic and then fixing

[Moult]

One more reminder: we still haven't actually solved the initial issue of this bugreport ... what is the EPSG code of WGS84? Is it just EPSG 4326?

This is the original quote from @LeeGregory12d which made me think that just saying "WGS84" is not sufficient for long/lats:

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.

If @LeeGregory12d is correct (I'm not a domain expert) and it is not enough to define the Longitude and Latitude for a point, then what are we missing? What can we add to the docs to make it unambiguously define the long/lats?

I thought that the EPSG code would help, and based on my understanding we should probably say EPSG:4326 - https://gis.stackexchange.com/questions/48949/epsg-3857-or-4326-for-googlemaps-openstreetmap-and-leaflet

After re-reading @LeeGregory12d's comment actually perhaps what is also important is the epoch. I searched online and found this link:

https://community.esri.com/t5/coordinate-reference-systems-questions/what-epoch-is-gcs-wgs-1984-in-10-4/td-p/877307

I am not qualified to interpret it. Does it mean that IFC needs to have a sentence which specifies ITRF00 or ITRF08 or something like that?

Ping @LeeGregory12d @SergejMuhic @pjanck

[pjanck]

Propose to add EPSG:4326 with epoch 1984 to the documentation. It resolves disambiguity and most probably reflects what the original authors had in mind (see also a historic summary above).

[Moult]

Thanks @pjanck ! Would be good to get another geoferencing expert to confirm the epoch choice. It seems there are quite a few out there.

[Moult]

@TLiebich in another post, @pjanck makes an excellent point that a pset may not work very well because latlongs and north are sampled at a particular easting and northing, but if an IfcSite does not have a representation, we have no idea what easting / northing / CRS it is sampled at.

In that case, to have the ideal scenario of having all latlong/north sampled at the same spot, we'd need a different location to put it. I'd go back to the original proposal of adding them as attributes to IfcMapConversion. Not for IFC4.3, of course, but something to consider for IFC5.

[aothms]

but if an IfcSite does not have a representation

But it would have a placement right? So it does establish a local origin. Or you could have a cartesian point representation if you prefer it to be different from the cartesian engineering system.

[Moult]

@aothms unfortunately the placement is no longer enough. In the past, when the georeferencing user-guide only talked about one map conversion, life was simple: you just get follow all your object placements, then apply the map conversion using the equations they tell you and that was it - you get your eastings and northings of the point. Great, so now you know that your lat longs = those particular eastings / northings.

Now, every geometric representation (model, plan) has its own map conversion. So there are likely going to be a minimum of 2 map conversions on the average project. You'd hope they match, but good luck :) On infra projects, apparently you can even have multiple map conversions with intentionally different eastings / northings, say for example one for a bridge very far away from another one for another bridge.

So which map conversion do you apply? No idea. The only thing that connects an object to a map conversion unambiguously is a representation with a representation context which has a coordinate operation. So an IfcSite with no representation is ambiguous as to which map conversion it is referring to - are the lat longs sampled at easting / northings of bridge A, or bridge B?

[TLiebich]

not sure whether I fully comprehend this - when was it decided that two geometric representation contexts can have different map conversions? Doesn't it opens a can of worms?

I tried to also read through #317 and the example with the two bridges, each refering to a different coordination context really scares me - up till now this was neither possible nor acceptable in IFC, I would assume it would crash almost all viewer, etc. - such a critical increase in scope can not be done via (and deeply embedded) issues.

In my view, we have to withdraw it.

[Moult]

@TLiebich it was news to me as well in #317 when @pjanck mentioned it. I thought I was simply not aware of the change.

My view is that if we (at least for now) keep the existing behaviour where a project has 1 map conversion (or 2 identical ones, one per context as per the cardinality bug in #317), then all of the current georeferencing bugs have solutions. Not perfect solutions, but they have solutions.

Once you introduce multiple map conversions, It's uncharted territory.

[TLiebich]

@Moult - exactly - and I want to avoid that the start the journey through such uncharted territory by an issue resolution. Such severe changes / extensions of IFC require proper ifc extension projects with user need and implementer feedback.

-1 from me so far

[Moult]

I 100% agree.

I vote to fix existing behaviour with the assumption of one map conversion. With that assumption, all the existing proposals make sense.

For IFC5 if things develop for multiple map conversions, so be it, but that is IFC5, not IFC4.3, which has promised basic georeferencing since IFC4 for many years.