True north should be specified at where it is sampled

[Moult]

Originally something I discussed here: https://forums.buildingsmart.org/t/how-is-true-north-and-magnetic-north-stored-in-ifc-and-how-does-it-interact-with-grid-north/3491

When a map conversion is supplied, the true north becomes a calculated value at a particular easting and northing. For example, at Easting X and Northing Y, the true north vector is (A,B).

The current description of true north has this sentence:

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.

I propose this modification to the description:

NOTE If a geographic placement is provided using IfcMapConversion then the true north is for information only, as calculated at the eastings and northings of the project origin. In case of inconsistency, the value provided with IfcMapConversion shall take precedence.

Ping @LeeGregory12d @SergejMuhic

[ccast1]

to be fixed by @aothms

[Moult]

If #323 is solved, here is a revised proposal for the property description:

NOTE If a geographic placement is provided using IfcMapConversion then the true north is for information only, as calculated at the eastings and northings of the related IfcSite object placement. In case of inconsistency, the value provided with IfcMapConversion shall take precedence.

[pjanck]

I don't think that using IfcSite is a good choice, since it isn't necessary to have one in the dataset.

I propose to change to the as calculated at the coordinate origin of the geometric representation context's coordinate system or sth similar. After all, both are attributes of the context entity.

[Moult]

@pjanck sure, that makes sense, but that means that we need to add lat/longs as described in #323 as attributes somewhere too (either on the context, or map conversion). It's a bad idea to have latlongs in one spot and true north in another.

What do you think @SergejMuhic ? You had proposed the pset.

[pjanck]

What do lat/long of IfcSite have to do with the TrueNorth of the context? These are independent from one another IMO.

[Moult]

@pjanck lat/longs are calculated at a particular easting / northing, just the same as true north (note, we are talking true north here, not grid north, which is given by the mapconversion xaxis). Given that latlongs and true north are both used for the same usecase (i.e. architectural solar studies / weather), it would be preferable to be sampled at the same spot.

[pjanck]

Note: I'm coming from the perspective of "there is IFC documentation, how to interpret it - ambiguities need resolution" and not "I have this use case, where to find information required - add/amend the documentation".

Therefore:

• IfcSite (usually) does not have a representation, thus does not know about TrueNorth, but the elements with representation contained in the site do.
• IfcSite's placement defines the root of placements and is not relative to any other placement. The lat/long/height, as I interpret current documentation, provide information about it's placement's origin in lat/long terms. It does not say anything about the orientation in space.
• Multiple context may be oriented differently (on site). Thus, each has its own TrueNorth to tell the geometries residing within it, where the true north is for the context. I agree that it is not the same as grid north.

it would be preferable to be sampled at the same spot

I agree with this requirement. However, I'm unsure how to resolve it. I agree with putting this in a PSet. I don't have a problem with things staying as they are - allowing for improvements in documentation, which are always welcome.

Meta: I see this as a clear issue that a placement isn't linked to a context. Thus, the ObjectPlacement of an IfcSite cannot tell within which context it is to be interpreted and thus within which georeferenced system the placements reside. A link would solve multiple problems (e.g. prefabricated objects during prefabrication, transport, and finalized 'context') and has been mentioned by @SergejMuhic plentiful of times already. I believe it was branded an IFC5 issue?

[Moult]

... and not "I have this use case, where to find information required - add/amend the documentation".

FYI @TLiebich summarises the history of lat longs here - this usecase is fundamental to the existence of latlongs. That's why this is important - if latlongs are sampled at the IfcSite, and the IfcSite has a object placement at 0,0,0 and a building is off at some large coordinate, then the lat longs are far away from the building and give incorrect solar results.

The lat/long/height, as I interpret current documentation, provide information about it's placement's origin in lat/long terms.

Which is meaningless, since we don't know at what eastings / northings it was sampled at since it has no representation. Yes?

Meta: I see this as a clear issue that a placement isn't linked to a context.

Yes. This is a problem. This is also why the Pset solution won't work, since we cannot guarantee that the site will have a representation.

I no longer have a solution for this problem now that I consider there may be multiple contexts at different map conversions.

[TLiebich]

see als my comment at #323 "now that I consider there may be multiple contexts at different map conversions" - honestly - where was this decided?

[Moult]

@TLiebich maybe it is not decided. I only heard about it in #317 and assumed it was an infra addition.