IVS-79/LAY000 - Presentation Layer Assignment

[Ghesselink]

A couple of remarks;

• The schema does not allow for any other entity type than IfcPresentationLayerAssignment for the attribute LayerAssignments (of IfcShapeRepresentation). It seems it's not possible to assign any other entity than mentioned above due to the assigning taking place by the AssignedItems (of IfcPresLayerAssign) attribute. Therefore, I think it would be redundant to add this explicitly in a gherkin steps; solely Its attribute LayerAssignments suffices.
  
  

• The not-activated file has the following list in context.instances that is getting handled by the then step.
  

• The activated file has the following instances in the stack for the last then step. Index 5 and 7 (both IfcPresentationLayerAssignment) activate the rule.
  

[evandroAlfieri]

great work

[aothms]

I must say I find this functional part not something I would advise end users to make decisions on.

[aothms]

geometry layers != layers information

Shouldn't this be consistent?

[Ghesselink]

Changed it to
The IFC model contains information on the selected functional part
See #257 (comment)

[aothms]

Better english would be layer, but I would also really add the word Presentation, so that it's not to be confused with the physical material layers for compound structures such as walls and slab (IfcMaterialLayerSet). Lastly since again it doesn't really contain information about these layers, I would call it assignment. And then accidentally I have arrived at the verbatim entity name.

Suggested change

	Feature: LAY000 - Layers Information
	Feature: LAY000 - Presentation Layer Assignment

[Ghesselink]

A single name for the entity and the functional part, that sounds consistent
Modified it
We'll also have to modify the feature filename in that case.

[aothms]

There is one additional consideration, that's a bit in detail, but actually you can have layer assignment on the representation but also on the items. This is missing in the concept template, but is rendered in the documentation.

I would actually add this, because semantically it makes more sense for me to assign the representation item than to assign the representation itself.

    Scenario: Layer assignment to representation

    Given an IfcProduct
    Given its attribute Representation
    Given its attribute Representations
    Given its attribute LayerAssignments

    Scenario: Layer assignment to representation items

    Given an IfcProduct
    Given its attribute Representation
    Given its attribute Representations
    Given its attribute Items
    Given its attribute LayerAssignments

[aothms]

Is the check that this is not empty in the The IFC model contains information on implementation? That's a bit implicit.

Should there not be something like:

Given its attribute LayerAssignments is not empty

or separated into two steps?

[Ghesselink]

The two statements are similar and, for activation, they function the same. The difference lies in which entity is selected for the next step. For these 000 rules, we don't evaluate the instances but simply check if they exist in the model. If the LayerAssignments attribute in an IFC file isn't empty, the rule will activate regardless of which statement we use.

Currently, the last instances in the stack (if any) are of type IfcPresentationLayerAssignment. With the 'is not empty' statement, they will be of type IfcShapeRepresentation (filtered out by the current statement from the previous Given statement).

[Ghesselink]

Outdated #281