IDSProperty.getEntities (the applicability path) collects applicable elements exclusively by walking each property set's DefinesOccurrence back-relation (from IfcRelDefinesByProperties). Property sets attached to a type, via IfcRelDefinesByType and reached through the type's HasPropertySets, carry no DefinesOccurrence relation at all, so elements whose matching pset exists only on their type are never selected as applicable. This is independent of the DefinesOcurrence/DefinesOccurrence spelling issue (ThatOpen/engine_fragment#270) and persists after fixing it.
Reproducible with a minimal single-wall IFC converted with the current IfcImporter: the wall type's pset shows relation keys [HasProperties] only, while every instance-attached pset shows [HasProperties, DefinesOccurrence]; an applicability facet naming the type's pset collects nothing.
Note the inconsistency with the requirement path: test() already inherits type psets via getTypePsets (added for #708), so an element can pass a requirement on a type-attached pset yet never be selected by an applicability facet naming that same pset. A fix would need getEntities to also traverse type psets and map them to instances through the corresponding type-to-instance back-relation.
IDSProperty.getEntities (the applicability path) collects applicable elements exclusively by walking each property set's DefinesOccurrence back-relation (from IfcRelDefinesByProperties). Property sets attached to a type, via IfcRelDefinesByType and reached through the type's HasPropertySets, carry no DefinesOccurrence relation at all, so elements whose matching pset exists only on their type are never selected as applicable. This is independent of the DefinesOcurrence/DefinesOccurrence spelling issue (ThatOpen/engine_fragment#270) and persists after fixing it.
Reproducible with a minimal single-wall IFC converted with the current IfcImporter: the wall type's pset shows relation keys [HasProperties] only, while every instance-attached pset shows [HasProperties, DefinesOccurrence]; an applicability facet naming the type's pset collects nothing.
Note the inconsistency with the requirement path: test() already inherits type psets via getTypePsets (added for #708), so an element can pass a requirement on a type-attached pset yet never be selected by an applicability facet naming that same pset. A fix would need getEntities to also traverse type psets and map them to instances through the corresponding type-to-instance back-relation.