Simplifying relative positioning with IfcPositioningElement

[pjanck]

Description of the proposal:

With the change of IfcObjectPlacement having a RelativePlacement attribute, the encoding of relative placement can be simplified greatly.

Currently, one needs to account for the IfcPositioningElement::ObjectPlacement when calculating the correct origin and rotations of the context in which a IfcGridPlacement or IfcLinearPlacement are defined. My proposal is to require the IfcObjectPlacement entity as referenced by IfcPositioningElement::ObjectPlacement to always be the ::RelativePlacement of every IfcObjectPlacement that is done within the context of said IfcPositioningElement.

Example:

Current way of obtaining the correct context of a IfcGridPlacement:

IfcGridPlacement 
--> ::PlacementLocation = IfcVirtualGridIntersection 
--> ::IntersectingAxes = IfcGridAxis 
--> ::PartOfU/V/W (INV) = IfcGrid 
--> ::ObjectPlacement = IfcObjectPlacement

Proposal:

IfcGridPlacement 
--> ::RelativePlacement = IfcObjectPlacement

Similar procedure applies to IfcLinearPlacement as well.

A very bad sketch of the schema needed to understand the example (MS Paint FTW):

Action We need to document this in the IfcPositioningElement as well as IfcObjectPlacement descriptions, introducing an informal proposition: For context dependent positioning (like IfcGridPlacement and IfcLinearPlacement), the IfcObjectPlacement::RelativePlacement needs to be filled with the ::ObjectPlacement of the corresponding IfcPositioningElement. Or something in the likes.

Is this a proposal to 'add', 'remove' of 'change' entities in the schema: change

What do we win:

• simplified traversion of IFC structure to obtain correct relative placement
• removal of inverses "pointing" from resource layer upwards

What do we lose:

• backwards compatibility?

Schema impact:

• removing PositioningElement inverse of IfcBoundedCurve
• removing PartOf.. inverses of IfcGridAxis

Instance model impact:

• none

Backwards compatible:

• Yes: from the physical file perspective. (given that IfcObjectPlacement::RelativePlacement change is out-of-scope of this change)
• No: for all implementers taking the inverses into account.

Automatic migration possible:

• Yes (given that IfcObjectPlacement::RelativePlacement change is out-of-scope of this change).

[SergejMuhic]

A few points:

1. Not an issue for Next-Gen as IFC4.2 introduced this.
2. How exactly this will be done is being discussed in Infra/Rail tech meetings, so long before Next-Gen.
3. Would lose the ability to relatively place grid and linear placements to each other. (probably a good thing)
4. Seems to be an MVD issue rather than schema. Otherwise, it should be handled with where rules and not informal propositions.

[pjanck]

To your points:

1. Goes with the next point.
2. Even better if we get it with 4x3_rc2 already.
3. I agree and see it as a good thing as well!
4. I'm all for a WHERE rule - probably demanding that IfcGridPlacement and IfcLinearPlacement have their RelativePlacement attribute filled with an instance of ifcLocalPlacement - and then specifying in the informal proposition that it has to be the same as the corresponding IfcPositioningElement uses?

[berlotti]

Good suggestion to simplify relative positioning.
IFC5 is an opportunity to improve and simplify lots of things. Relative positioning is very important as well to re-evaluate.
With the conformance levels replacing MVDs in IFC5, it is even more important to make sure that this is as efficient and effective as possible.
Focusing on WHERE rules alone is not a solution though, since the solution needs to work in other representations/languages as well.