If I have one IfcPresentationLayerAssignment with the Name set to “Foo”, and another IfcPresentationLayerAssignment also with the Name set to “Foo”, but the contents of the AssignedItems attribute is different, do I have two layers, or one layer?
Is there any WHERE RULE or formal / informal proposition that I missed in the documentation that a Name of a layer assignment is used as a key? I think the intention is that two identical names refer to the same layer, as per the image here, but I’d like to double check, as I didn’t see it explicitly mentioned
I don’t see anything that indicates that two instances of IfcPresentationLayerAssignment with the same name should represent a single layer only - neither in the instance depicted in the IFC specification (there are two layers with different names) nor in ISO 10303-46, where the presentation layer assignment is taken from, and also not in implementation agreements. An IfcPresentationLayerAssignment instance defines a layer and there is no restriction on uniqueness of the layer names, hence in your example there are two valid layers. That’s how I understand it.
And what do you expect software receiving such files would do? If the name is the same, why would you assume the layers may not be the same? (Maybe I don’t get it).
As the assignment has no GUID and the layer is only identified by name, why would you assume they are to be duplicated? The only identification they have is their name and if that is identical, I’d say they are meant as being identical.
Now what would happen if their description and identifier attributes are NOT the same, I wouldn’t know. But they are both optional. Agreed, this is not a robust approach, but this is not the only place in IFC where such things happen. I’ve seen examples of having multiple relationships each carrying some of the RelatedElements or RelatedObjects. In that case, I merged them in my viewer script.
@stefkeB that is why I started this thread - because my initial reaction would be to merge them based on name, which is their only identifier.
This is a common issue with a few other entities in IFC - another example is styled items and surface styles, which I’ve seen commonly duplicated but clearly from a human point of view the intention was to have them the same.
The current state of affairs is what @tauscher says - there is no explicit definition about names. I would support a proposal to amend the IFC spec to address this. Regardless of the solution - it should be mentioned in the spec, at the very least in the documentation, but ideally as a where rule or similar.
I don’t believe that the “name” attribute being used as an identifier is the unspoken intention of the specification. The attribute’s name “name” does already provide a hint for the attribute semantics - “names” are usually not unique and multiple things can go by the same name, yet be different things.
It would also not occur reasonable to me to “merge” layers with the same name. If they have different visibility or style, then which do you keep and which discard? Which do you apply? What about a round trip, do you throw away information? (Ok, this last one does not matter for a read-only implementation such as a viewer.) But for these reason I would keep both layers and show them as they are (with the same name). A user or software can fix this if they like.
The question is rather: How did the two layers with same name get in there and should it be illegal? I would speculate that this results from a merge and find it perfectly reasonable to keep both layers. I think (speculative again) merges could actually have been the reason for the schema authors to model it this way. Of course we could have namespaces with unique names prescribed in the schema, but then during a merge the same-name-layers would have to be renamed (not merged), I believe. Would that win us anything? And is the price acceptable?
