IfcLinearPlacement.RelativePlacement and -.CartesianPosition lack description

[aothms]

cc @pjanck @SergejMuhic

I think the main potential point of confusion that needs to be clarified is on CartesianPosition. I assume this the equivalent transform expressed as a non-linear explicit placement.

(from https://github.com/IfcOpenShell/IfcOpenShell/issues/3098#issuecomment-1773273725)

Proposal:

RelativePlacement

Geometric placement derived from a location on a curve that defines the transformation from the related coordinate system into the relating.

CartesianPosition

Optional explicit equivalent of RelativePlacement that can be used by software that does not support evaluating linear placements.

[SergejMuhic]

I think the main potential point of confusion that needs to be clarified is on CartesianPosition.

Agree. I think this should be removed as a matter of fact. A placement to cover that scenario is already IfcLocalPlacement. It creates confusion. Redundancy is a pain in the butt. I would prefer to just create a file with local placements for software that does not support evaluating linear placements.

I would amend the description for RelativePlacement a bit: Geometric placement defined by a measurement along and offsets from a curve that defines the transformation from the related coordinate system into the relating.

CartesianPosition agree. As long as it's clear what takes precedence. If a software evaluating the linear placement produces a different cartesian positions it has to be clear who is correct.

NOTE Regarding IfcAxis2PlacementLinear I would prefer just using IfcPointOnCurve and model any offsets as IfcAxis2Placement3D and deprecating IfcPointByDistanceExpression but let's not re-open this discussion. 😄 Just letting you know.

[aothms]

I would prefer to just create a file with local placements for software that does not support evaluating linear placements.

I tend to agree. Although I can't really judge it due to my limited domain knowledge.

Geometric placement defined by a measurement along and offsets from a curve that defines the transformation from the related coordinate system into the relating.

I like it 👍

One more point about CartesianPosition. @RickBrice found the definition from 4.2:

Indicates the calculated global location and orientation in Cartesian coordinates as a fallback which may be used by applications that do not support linear placement.

Which mentions global. I would suppose CartesianPosition is merely the equivalent of RelativePlacement (IfcAxis2PlacementLinear). So still relative to the placement defined in PlacementRelTo. Or do you think it would be absolute/global?

[SergejMuhic]

In 4.2 at the conceptualization of IfcLinearPlacement we did not have the IfcPositioningElement completely thought through. Now that it has

HasPlacement

EXISTS(SELF\IfcProduct.ObjectPlacement)

I think it is better to use the relative position of the IfcPositioningElement.

[aothms]

I think it is better to use the relative position of the IfcPositioningElement.

I agree. I think the local placement of the IfcPositioningElement in practice has to be equal to IfcLinearPlacement\IfcObjectPlacement.PlacementRelTo? (How else are linearly positioned elements going to line up with the alignment). We have the same for GridPlacement btw. also there -practically- PlacementRelTo has to be equal to the ObjectPlacement of the Grid.

Is this / should this be documented or can you think of cases where this is not true?

[pjanck]

I have no strong opinions regarding the wording of the documentation, as long as it is clear. +1 on @SergejMuhic suggestion.

So still relative to the placement defined in PlacementRelTo.

Yes, that is how I remember the discussions. CartesianPosition would be a fallback for the reading software, if linear placement is not understood / to double check the calculation. But never to take precedence in case of mismatch.

I think the local placement of the IfcPositioningElement in practice has to be equal to IfcLinearPlacement\IfcObjectPlacement.PlacementRelTo?

Agreed for most(?) cases. See point 1. here for an example in practice.

Is this / should this be documented

Hoping to see this in General Usage.

can you think of cases where this is not true?

I can imagine that not every linear placement would be along a curve corresponding to a linear positioning element. For example, something could be placed 5 meters along the centreline of a retaining wall, which is modelled as IfcWall with an Axis representation. (The wall is either IfcWall or IfcLinearPositioningElement, but not both - that's just a consequence that EXPRESS doesn't provide interfaces ...) In this case, [Sth].ObjectPlacement.PlacementRelTo would need to point to IfcWall.ObjectPlacement. Note though: if linearly placing along something else than IfcLinearPositioningElement is something IFC should support, is a discussion for General Usage / MVD.

[aothms]

The wall is either IfcWall or IfcLinearPositioningElement, but not both - that's just a consequence that EXPRESS doesn't provide interfaces

Well... 'IFC' made a conscious choice to forbid multiple inheritance and also introducing a specific concept IfcPositioningElement disjoint from IfcElement. From those choices I would derive that an IfcWall must not be used to linearly position elements. Even if in some cases (like your example) it functions like that, I would argue that an alternative modelling approach must be sought in that case.

There is also some evidence in the IfcRelPositions entity, which is clear in the fact that the RelatingPositioningElement is strictly of type IfcPositioningElement.

Consider this analogy. "Can an IfcCurtainWall be a grid with IfcGridAxes". It can't, this time because the schema doesn't allow it (because somehow we chose to model GridAxes not as nested products... but as direct attributes) even though functionally I can imagine a facade is designed as such. So also in that case, if one wants to express the grid-like nature of the curtain wall, they would have to choose a different paradigm to model that.

Or another analogy, courtesy of some of the IFC5 discussions earlier on. Some funky building was designed where the stair handrail was also the space heater. You can't assign a Pset_SpaceHeaterTypeCommon to the IfcRailing because the spec doesn't allow it. So you somehow need the elements side by side.

The IFC5 discussion nowadays gravitates around Entity-Component(-System). Maybe it means that certain interface-like traits become a possibility. Interesting. I wouldn't know.

Note though: if linearly placing along something else than IfcLinearPositioningElement is something IFC should support, is a discussion for General Usage / MVD.

So, all in all I would say this is not an MVD thing. This is a somewhat conscious choice in the IFC spec and we need to live by it. Even if in some cases it limits the freedom of expression to some extent. Gratuitous flexibility hurts more.

---

Going back to the main points of this thread:

RelativePlacement Geometric placement defined by a measurement along and offsets from a curve that defines the transformation from the related coordinate system into the relating.

CartesianPosition Optional explicit equivalent of RelativePlacement expressed as Cartesian coordinates which may be used by applications that do not support linear placement.

I would propose to add a sentence to IfcLinearPlacement (for IfcGridPlacement we already have something similar in the change note).

NOTE In typical usage, SELF\IfcObjectPlacement.PlacementRelTo will point to the ObjectPlacement of the IfcLinearPositioningElement that SELF.RelativePlacement.Location\IfcPointByDistanceExpression.BasisCurve is represented by. This enables that the alignment curve and linearly positioned elements are correctly positioned with respect to each other when evaluating the global transformations.

[SergejMuhic]

I can imagine that not every linear placement would be along a curve corresponding to a linear positioning element. For example, something could be placed 5 meters along the centreline of a retaining wall, which is modelled as IfcWall with an Axis representation. (The wall is either IfcWall or IfcLinearPositioningElement, but not both - that's just a consequence that EXPRESS doesn't provide interfaces ...) In this case, [Sth].ObjectPlacement.PlacementRelTo would need to point to IfcWall.ObjectPlacement. Note though: if linearly placing along something else than IfcLinearPositioningElement is something IFC should support, is a discussion for General Usage / MVD.

I really cannot agree to this. The whole point of IfcLinearPositioningElement is to wrap linear positioning parameters in an object. So, say an IfcPolyline is both a representation of a linear positioning element as well as the IfcWall. To measure along a wall, the wall has an e. g. assigned linear positioning element. As a result, we have measured along the wall by means of assigning the wall resources to the linear positioning element. So, although there is no interfacing, there is the clear distinction between the resource and core layers.

Well... 'IFC' made a conscious choice to forbid multiple inheritance and also introducing a specific concept IfcPositioningElement disjoint from IfcElement. From those choices I would derive that an IfcWall must not be used to linearly position elements. Even if in some cases (like your example) it functions like that, I would argue that an alternative modelling approach must be sought in that case.

There is also some evidence in the IfcRelPositions entity, which is clear in the fact that the RelatingPositioningElement is strictly of type IfcPositioningElement.

Yes.

So, all in all I would say this is not an MVD thing. This is a somewhat conscious choice in the IFC spec and we need to live by it. Even if in some cases it limits the freedom of expression to some extent. Gratuitous flexibility hurts more.

Do not agree with this though. Not multiple inheritance but supporting measuring along features, I would say that concept templates should be provided to model this. If nothing else, bSI has an agreement with OGC to provide an interface on the alignment and ISO19148 level. Stakeholders agree with this and this was a clear requirement when designing the entities in question.

Sorry to keep this rolling. These discussions were had and we can take them into another thread but I had to respond since the thread diverged unnecessarily.

Regarding thread, the proposed NOTE is IMO already documented where it belongs in the Product Linear Placement template: https://bsi-infraroom.github.io/IFC-Documentation-Tunnel/4_4_0_0/general/HTML/link/product-linear-placement.htm https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Product_Shape/Product_Placement/Product_Linear_Placement/content.html See last paragraph.

This is still true even with Product Relative Placement because the product is not linearly placed but locally based on the linear placement of the referent i. e. the station / position.