Proposal to add equation for local engineering coordinate system to map coordinate system conversion

[Moult]

The equation for converting between local engineering coordinate systems to map coordinate systems is incredibly important, and already covered in the geolocation user guide. There are three problems:

1. The geolocation guide is an auxiliary document, which contains vital implementation formulas. Since it is separate, implementers may miss it. This information should belong in the official IFC documentation.
2. The guide is a PDF and harder to update and track changes. By migrating relevant portions to the official docs, it will become easier to update.
3. Portions need updating for IFC4.3 (some covered in this issue), including some other issues mentioned on the buildingSMART forums.

This is the bit important for implementers:

The transformation is applied as follows to convert coordinates from local to map grid:

E = (A X) - (B Y) + Eastings N = (B X) + (A Y) + Northings H = Z + OrthogonalHeight A = Scale cos(Rotation) B = Scale sin(Rotation) Rotation = atan2(XAxisAbscissa, XAxisOrdinate)

I propose to amend it to the following, and insert it into the documentation for IfcMapConversion:

The transformation is applied as follows to convert coordinates from local to map grid:

E = (A X) - (B Y) + Eastings N = (D X) + (C Y) + Northings H = (ScaleZ Z) + OrthogonalHeight A = Scale cos(Rotation) B = Scale sin(Rotation) C = ScaleY cos(Rotation) D = ScaleY * sin(Rotation) Rotation = atan2(XAxisOrdinate, XAxisAbscissa)

Note: in software functions, the atan2 operation is sometimes implemented either as atan2(y, x) (e.g. in Python) and at other times as atan2(x, y) (e.g. in Excel). Therefore, this may either be Rotation = atan2(XAxisAbscissa, XAxisOrdinate) or Rotation = atan2(XAxisOrdinate, XAxisAbscissa)

Note: this is a guess only on how the formula should be amended for the separated scale factors. I am not a mathematician, and it is likely that my guess is totally incorrect. Also, I am assuming that atan2 is significant and not equivalent to arctan(y/x) (more reading on why atan2 is different from atan and therefore arctan)

Ping @LeeGregory12d to confirm this proposal :)

[LeeGregory12d]

IN the latest update to User Guide the definition for rotation has been modified so that there is no confusion. That is, it is now:

Rotation = arctan(XAxisAbscissa/XAxisOrdinate)

[Moult]

Thanks @LeeGregory12d - so you are sure there is no difference between atan2 and arctan (I linked to a webpage describing the difference) which @hlg pointed out? Also, isn't it arctan(y/x) not arctan(x/y)? If so, here is the revised proposal:

The transformation is applied as follows to convert coordinates from local to map grid:

E = (A X) - (B Y) + Eastings N = (D X) + (C Y) + Northings H = (ScaleZ Z) + OrthogonalHeight A = Scale cos(Rotation) B = Scale sin(Rotation) C = ScaleY cos(Rotation) D = ScaleY * sin(Rotation) Rotation = arctan(XAxisOrdinate / XAxisAbscissa)

Note: in software functions, the arctan operation is sometimes implemented either as atan2(y, x) (e.g. in Python) and at other times as atan2(x, y) (e.g. in Excel). Therefore, this may either be Rotation = atan2(XAxisOrdinate, XAxisAbscissa) or Rotation = atan2(XAxisAbscissa, XAxisOrdinate) respectively.

Can you also verify my changes regarding the new Scale attributes?

[LeeGregory12d]

I haven't seen Ordinate and Abscissa used since high school so I have to always double check which is which (which I didn't just do :( )

Yes it should be arctan (y/x). That is arctan (XaxisOrdinate/ XaxisAbscissa)

[Moult]

Awesome! How about the scales? You'll see I had an attempt to modify the formula to accommodate ScaleY and ScaleZ but since I don't know math very well I have no idea if I did it correctly or not :)

[LeeGregory12d]

I don't know what the equations should be if ScaleX != ScaleY. I presume it is the case of just a Translation in x and y, a Scale in x and y and a rotation in (x,y) plane but as I don't have any infrastructure examples in mind, someone with the ScaleX != ScaleY case is needed.

ScaleX!=ScaleY occurs for a 2D Affine transformation but in general a 2D Affine does not keep the axes perpendicular and so there is then shear parameter floating around.

[Moult]

OK - so we will need someone with experience where ScaleX != ScaleY to verify / propose the new equations.

Ping @berlotti do you know who this might be?