IfcPositioningElement documentation errors

[RickBrice]

These issues related primarily to IfcPositioningElement

1. The first sentence should be revised to "An abstract entity definition for positioning and annotating elements that are used to position other elements relatively.". The word "New" is unnecessary. At what point does this entity cease to be "new"? The change log indicates IfcPositionElement was new in IFC 4.1
2. The abstract icon is missing
3. The formal proposition clearly states that ObjectPlacement is required for grid. However, when defined at this level, it is applied to all subtypes. This has led to an invalid implementation in the validation service. IfcReferent without ObjectPlacement are flagged as an error. IfcReferent is not a subtype of IfcGrid, therefore the formal proposition should not apply.

[aothms]

The formal proposition clearly states that ObjectPlacement is required for grid

I'm not sure what the intent was here. Are we sure this is not intentional just without improper type references when definitions were shifted over the course of 4.1 conceptualisation? (These kind of discrepancies were visible in other places as well (mostly concept usages) that text is copied/moved without updating the entity name references.) It's not odd to expect that an positioning element has a position

4. HTML markup to be removed from the description

[RickBrice]

Since IfcPositioningElement are "used to position other elements relatively", with relatively being the key word. A precise object placement doesn't seem necessary in all cases.

For the case of IfcReferent. We know the relative position of the referent with respect to the alignment from IfcRelNests. We also know the relative position of the thing IfcReferent is positioning from IfcRelPositions. This allows for a semantic definition of where something is position, without the need for geometry. For example, IfcAlignment - IfcRelNests - IfcReferent - IfcRelPositions - IfcBridgePart.PIER. We know the pier is relative to the alignment and the pier is relative to other IfcReferent in the IfcRelNests.

Relative position of a grid isn't so clearly defined. The grid needs to anchor to a point and have an orientation.

Relative position of an alignment is similar to a grid. The alignment needs to be anchored somewhere.

So perhaps the formal proposition should apply to IfcGrid and IfcLinearPositioningElement.

[aothms]

Is this what you are describing:

IfcAlignment--------LocalPlacement <---------------+
     ^                                             |
IfcRelNests                                        |
     v                                             |
IfcReferent---------ObjectPlacement=$              |
     ^                                             |
IfcRelPositions                                    |
     v                                             |
IfcBridgePart.PIER--LinearPlacement.PlacementRelTo-+

Both inverses PositionedRelativeTo and Positions have cardinality SET [0:?] so they cannot be depended on.

I think a more logical sketch would be

IfcAlignment--------LocalPlacement <---------------+
     ^                                             |
IfcRelNests                                        |
     v                                             |
IfcReferent---------LinearPlacement.PlacementRelTo-+
     ^                       ^                      
IfcRelPositions              +---------------------+
     v                                             |
IfcBridgePart.PIER--LocalPlacement.PlacementRelTo--+

In other words the referent carries the position. And the PIER is position relative to the Referent. This is a bit redundant because then you have Offsets both defined in IfcPointByDistanceExpression.Offset... and IfcLocalPlacement.RelativePlacement

But I'm probably slightly misreading your post.

[RickBrice]

Maybe I'm just confused. I thought the semantic and geometric representation of things where somewhat independent from one another, being linked by IfcProduct.ObjectPlacement and IfcProduct.Representation. ObjectPlacement and Representation are optional, and when omitted only a semantic representation is defined.

IfcReferent provides the semantic representation of the relative position of an element (IfcBridgePart.PIER) to the positioning element (IfcAlignment). It is not a precise geometric position. If the IfcReferent has a Pset_Stationing, then the station of the pier is known, which is semantic information. This is modeled as shown here, and, of course, is optional if the modeler does not desire to represent the relative location (hence PositionedRelativeTo and Positions could be empty sets).

IfcAlignment--------IfcLocalPlacement
   ^
IfcRelNests
   v
IfcReferent
   ^
IfcRelPositions
   v
IfcBridgePart.PIER

The geometric position of a pier is

IfcAlignment.Representaton.Representations.Items.Curve<------------------------------+
                                                                                     |
IfcBridgePart.PIER---IfcLinearPlacement.RelativePlacement.Location.DistanceAlong     |
                                                                  .BasisCurve--------+

[SergejMuhic]

Is this what you are describing:

IfcAlignment--------LocalPlacement <---------------+
     ^                                             |
IfcRelNests                                        |
     v                                             |
IfcReferent---------ObjectPlacement=$              |
     ^                                             |
IfcRelPositions                                    |
     v                                             |
IfcBridgePart.PIER--LinearPlacement.PlacementRelTo-+

Both inverses PositionedRelativeTo and Positions have cardinality SET [0:?] so they cannot be depended on.

I think a more logical sketch would be

IfcAlignment--------LocalPlacement <---------------+
     ^                                             |
IfcRelNests                                        |
     v                                             |
IfcReferent---------LinearPlacement.PlacementRelTo-+
     ^                       ^                      
IfcRelPositions              +---------------------+
     v                                             |
IfcBridgePart.PIER--LocalPlacement.PlacementRelTo--+

In other words the referent carries the position. And the PIER is position relative to the Referent. This is a bit redundant because then you have Offsets both defined in IfcPointByDistanceExpression.Offset... and IfcLocalPlacement.RelativePlacement

But I'm probably slightly misreading your post.

This is not compliant with ISO 19148. The known locations on the alignment such as MILEPOSTS or KILOPOSTS are nested and can be measured from i.e. referents. These themselves do not position in the sense of describing a linear reference position of a feature. The nesting relationship allows for simpler predecessor and successor queries. This was supposed to be in General Usage but since the Infra MVD project was not approved, it remained unspecified.

Relative position referents are positioned relatively to a known position. These are related with IfcRelPositions and should have a different PDT. The IFC data model deviates a bit from OGC here because we do not use interfaces. But my explanation above is what was approved by OGC.

3. The formal proposition clearly states that ObjectPlacement is required for grid. However, when defined at this level, it is applied to all subtypes. This has led to an invalid implementation in the validation service. IfcReferent without ObjectPlacement are flagged as an error. IfcReferent is not a subtype of IfcGrid, therefore the formal proposition should not apply.

On this I would argue that according to ISO 19148 referents require a position. I think we should be compliant with OGC here since the alignment related concepts are the interface to their standards.

[RickBrice]

Thank you for the explanation. I will find a copy of ISO 19148 and get up to speed with that.

I amend my issue to the following:

1. The first sentence should be revised to "An abstract entity definition for positioning and annotating elements that are used to position other elements relatively.". The word "New" is unnecessary. At what point does this entity cease to be "new"? The change log indicates IfcPositionElement was new in IFC 4.1
2. The abstract icon is missing
3. The formal proposition clearly states that ObjectPlacement is required for grid. This should be changed to “ObjectPlacement is required”.
4. HTML markup to be removed from the description

[TLiebich]

I second the four requested improvements and would like to add;

1. "An abstract entity definition for non-physical elements that are used to position other elements. An IfcPositioningElement provides a position and may provide annotations." -- "relatively" can be dropped and the definition of a positioning elements should contain its main purpose "to position other elements". The term "non-physical" can be questioned, I am OK to omit.
2. in addition: the inheritance graph is missing, which is normally shown at each entity, same for the attribute definitions, both sections are missing, so the two inverse attributes are not described