Deprecate all IfcPreDefinedPropertySet - was IfcPermeableCoveringProperties's ShapeAspectStyle attribute

[Moult]

The ShapeAspectStyle attribute of all other IfcPreDefinedPropertySet have been deprecated, except for IfcPermeableCoveringProperties. Why is this an exception?

If there is no reason for it to be an exception, I propose to deprecate it.

[TLiebich]

just an offsight, no exception actually we should deprecate the whole entity IfcPermeableCoveringProperties and move these attributes into a property set. To my knowledge it never was a part of an official MVD.

[Moult]

@TLiebich how about migrating all the IfcPreDefinedPropertySet to pets?

[TLiebich]

I would personally vote for it. None of them are part of IFC4 RV (and therefore should be kept for strict compatibility reasons). Better to unify the use of property sets now in 4.3.

[Moult]

Making this as decided unless any objections.

[aothms]

So this means copying all IfcPreDefinedPropertySet from entities to psets. That's easy in UML. They're both just classes. And deprecate the IfcPreDefinedPropertySet entities.

What do we deprecate? Do we deprecate the abstract entity and make it carry over through inheritance in the docs or do we just label everything as deprecated?

What do we do with the concepts such as Window attributes: that currently link to the deprecated predefined propsets:

http://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Object_Attributes/Object_Occurrence_Attributes/Element_Occurrence_Attributes/Window_Attributes/content.html

Technically we can replicate the structure using non-predefined propsets where the propertyset name and the property names become constraints. But it's not really logical I guess. They aren't "attributes" anymore and probably there are already propertyset properties that are equally significant so it's strange to highligh only the panel/frame ones.

[Moult]

Righto so from what I thought was "let's just deprecate this one property to be consistent" could explode into "let's clean up this mess of unstandardised IfcPreDefinedPropertySet"

Revised WIP proposal:

• Remove concept Door attributes (it's now just psets)
• Remove concept Window attributes (it's now just psets)
• (yes there are other element occurrence attributes which could be migrated to psets but let's take this one step at a time)
• Remove concept Door type attributes (it's now just psets)
• Remove concept Window type attributes (it's now just psets)
• Label individually explicitly as deprecated, inherited deprecation may not be a good idea in the future if we want to cut out a layer.
• Label as deprecated IfcDoorLiningProperties IfcDoorPanelProperties IfcWindowLiningProperties IfcWindowPanelProperties IfcPermeableCoveringProperties and IfcReinforcementDefinitionProperties
• Pset_DoorLining, Pset_DoorPanel, Pset_WindowLining, Pset_WindowPanel gets added, looks straightforward from a glance, with the ShapeAspect property removed, TYPEDRIVENOVERRIDE
• Pset_PermeableCovering added, applicable to IfcDoor and IfcWindow with TYPEDRIVENOVERRIDE

~~The problem now, is how do we convert them into psets? A door may have multiple panels, but we can only assign Pset_DoorPanel once, unlike previously where you could have multiple IfcDoorPanelProperties.~~

[aothms]

A door may have multiple panels

This issue keeps coming back. I'd say if you want that use decomposition. Otherwise you can't recover the correspondences between psets and shape items anyway.

You can also see it as a conceptual problem with Psets that by instantiating a Pset, the identifier is equal to the type. I think it would have made sense to have a both the Pset name, but also an element-local pset identifier, so that you can have multiple psets with the same name, but different identifier.

[Moult]

Happy with the decomposition solution. Updated the proposal. What about how would Pset_ReinforcementDefinition work?

[TLiebich]

Pset_ReinforcementDefinition ? in relation to permeable covering.

there is a quite difficult, but already implemented, generic solution on adding multiple property sets to components, indicated as shape aspects - was proposed for IFC4 RV - see here.

[Moult]

Pset_ReinforcementDefinition ? in relation to permeable covering.

As part of the pitch to migrate all the IfcPreDefinedPropertySet to pets mentioned earlier in this thread.

I know nothing about reinforcing, maybe ping @Jesusbill who can help?

[aothms]

Yes, that's indeed a really really complex one. It doesn't match the the structure of a pset. And storing this information so disconnected from the geometry to me doesn't make a lot of sense. Actually it resembles to some extent the alignment concepts, maybe we can take lessons from this, but I'd be inclined to see deprecate and don't migrate to pset and revisit this in a proper project (did precast mvd look into this?)

[Moult]

I'd also be happy to see it deprecated (we don't want a straggler IfcPreDefinedPropertySet hanging around) and then it can come back with a more semantic approach.

[Moult]

I was working on checking out the standard cases and came across the door docs which reminded me about this issue. What are the changes of getting a decision on this one?

[aothms]

Well there's two aspects now. Consensus and time. I'm personally +1 with the proposal, but not sure if we find the time.

[Moult]

OK, let's not rush it then, even from a markdown change it's potentially significant from what I see.

[aothms]