Open pjanck opened 3 years ago
A few points:
To your points:
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?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.
Description of the proposal:
With the change of
IfcObjectPlacement
having aRelativePlacement
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 aIfcGridPlacement
orIfcLinearPlacement
are defined. My proposal is to require theIfcObjectPlacement
entity as referenced byIfcPositioningElement::ObjectPlacement
to always be the::RelativePlacement
of everyIfcObjectPlacement
that is done within the context of saidIfcPositioningElement
.Example:
Current way of obtaining the correct context of a
IfcGridPlacement
:Proposal:
Similar procedure applies to
IfcLinearPlacement
as well.A very bad sketch of the schema needed to understand the example (MS Paint FTW):![grafik](https://user-images.githubusercontent.com/59165496/101240782-be244b80-36f1-11eb-867c-d855dd916058.png)
Action We need to document this in the
IfcPositioningElement
as well asIfcObjectPlacement
descriptions, introducing an informal proposition: For context dependent positioning (likeIfcGridPlacement
andIfcLinearPlacement
), theIfcObjectPlacement::RelativePlacement
needs to be filled with the::ObjectPlacement
of the correspondingIfcPositioningElement
. Or something in the likes.Is this a proposal to 'add', 'remove' of 'change' entities in the schema: change
What do we win:
What do we lose:
Schema impact:
PositioningElement
inverse ofIfcBoundedCurve
PartOf..
inverses ofIfcGridAxis
Instance model impact:
Backwards compatible:
IfcObjectPlacement::RelativePlacement
change is out-of-scope of this change)Automatic migration possible:
IfcObjectPlacement::RelativePlacement
change is out-of-scope of this change).