Geolocation standards in IFC2X3 and IFC4

Developers
21

@tauscher is correct. There is objectively no right or wrong for the order. However, there is objectively a more common convention of y, x, which is why I make the proposal and call it “more correct” :wink: I also reemphasize in the proposal that a sentence is needed to clarify the order of operation, or reference to arctan(y/x).

More important than whether the reversal occurs (although I believe it should still be reversed, as to follow the more common convention), a clarifying sentence should be added.

22

Thanks.
I must admit I’ve never used Excel or Mathemtica for such calculations.
I suggest we write it out in full and not refer to a particular computer function.
That is:
Rotation = arctan(XAxisOrdinate/XAxisAbscissa)

1 Like
23

100% agree @lee.gregory :slight_smile:

In addition, the 3 proposals at the beginning of this thread are still outstanding.

24

Don’t forget that atan2(y,x) does a bit more than arctan(y/x). If you need that and don’t want to spell it all out, it could be better to stick with your original correction and mention in a footnote that some implementations of the atan2 function reverse parameters.

2 Likes
25

In addition to this, I have now been working with IFC geolocation with Cesium, Aerometrex, @john.mitchell and now @lee.gregory - and so I believe to ensure correct implementation it would be useful to supply some test files.

OSArch now provides the IFC2X3 geolocation conventions as a property set template definition which you can download: https://wiki.osarch.org/index.php?title=IFC_geolocation (by the way, the BlenderBIM Add-on can be used to author property set template definitions, should buildingSMART find it useful as a tool)

This should allow for unambiguous implementation of it. This also addresses an omission (I believe) in the buildingSMART user guide where MapUnit is not discussed. In particular, property sets do not allow an IfcNamedUnit, and therefore I have reverted it to IfcIdentifier.

You can now find two test files… for IFC2X3: https://github.com/Moult/ifc-test-files/blob/master/src/ifc-spf/geolocation-ifc2x3.ifc … and for IFC4: https://github.com/Moult/ifc-test-files/blob/master/src/ifc-spf/geolocation-ifc4.ifc

For these two files, you should expect to see the following result (I have provided WGS84 for convenience) - a quick sanity check should find the model in the Sydney Opera House :slight_smile:

EPSG:4326, or WGS84
   X: 151.2149915
   Y: -33.8567411

EPSG:7856, or GDA2020/MGA56.
   X: 334871.85
   Y: 6252295.02

EPSG:5111, or AHD.
   Z: 12
   Scale factor is 1.

The building itself is arrow shaped (how convenient!) with the center of the arrow around the project origin, pointing project north (Y axis - in green):

image

If properly geolocated, and true north is up the page, you should find the arrow pointing north east by 30 degrees:

image

Please let me know if you spot any errors, and it would be good to see some other vendors also produce files so we can ensure that we can consume and round-trip them properly.

26

Dion,
And I presume the centre point of the arrow should be at (334871.85,6252295.02,12.)

27

@lee.gregory sorry for the late reply! Happy holidays! Yes, correct. That is indeed the global coordinate of the origin / center of the arrow.

28

Bumping this thread, as it seems as though things such as XPath nominations still have not been confirmed, and the user guide has not been updated. This is quite worrying, as recently I have been made aware of issues like this which suggest that BIM authoring programs are producing likely inconsistent data.

Ping @jwouellette how can we take this forward and get this resolved?

1 Like
30

@Moult Maybe @berlotti can give us an idea about the best way forward.

1 Like