IFC Exports 2022 and 2023 change Uniformat Classification in to Uniformat (followed by the value in the assembly code)

[HenkMolhoek]

When exporting to IFC, the assembly code is converted to the Uniformat Classification.
Since update 2022.5.1.0 and the release of the exporter for 2023, this has been changed to Uniformat followed by the value in the assembly code.
For example if the Assembly Code = 21.21 the Uniformat 21.21 instead of Uniformat Classification.

Befor 2022.5.1.0
#154=IFCCLASSIFICATION('https://www.csiresources.org/standards/uniformat','1998',$,'Uniformat');
#155=IFCCLASSIFICATIONREFERENCE('https://www.csiresources.org/standards/uniformat','22.21','',#154);
#156=IFCRELASSOCIATESCLASSIFICATION('3NJnFoZ5XDJutd9hFQsTPZ',#20,'Uniformat Classification','',(#122),#155);

After 2022.5.1.0

#157=IFCCLASSIFICATIONREFERENCE('https://www.csiresources.org/standards/uniformat','22.21','',#95);
#158=IFCRELASSOCIATESCLASSIFICATION('3rmweuVfL43uBPuApjrTzo',#20,'Uniformat 22.21','',(#125),#157);

IFC EXPORT TEST.zip

Befor 2022.5.1.0

After 2022.5.1.0

[dvrvb]

Hi Henk, which version of Solibri are you using?
I can only get it reproduced with an old version of Solibri Viewer (9.7). With the current version of Solibri Office (9.13.0) I get the expected result as 1 tree "Uniformat". Only with the old version I get the 5 classification trees.

As I look to the code: indeed in the attribute the number is added, but that is an optional attribute.

As far as I know the real deal, is this reference pointing to # 156, and that looks OK.

So I suspect this is more a Solibri issue (of the past).

[louistrue]

I dont think so. Happens to me in the latest version as well, also in BimCollabzoom...

[dvrvb]

Would be very strange that the same file in the same version of Solibri is represented in different ways. I can only report what I see, and I see the expected result in 9.13.0, on two different PC configurations, also with the own reproduction of the IFC models. Sorry, than I don't have any clue.

[louistrue]

Ah, I'm sorry @dvrvb ! Didn't realize there was a Solibri update 3 days ago. Thanks for sharing.

I still dont think it was a problem on the viewer side since it always worked fine until exporter version 22.5.1.0 and I have trouble with different viewers...

[dvrvb]

But indeed it is also visible in the current version of BimcollabZoom

But not in BIM Vision, and not in FZK Viewer. So I think it would be helpful knowing the real meaning of that attribute. (I mean, if indeed that attribute is supposed to be used by the viewer).

[louistrue]

https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/lexical/IfcRelAssociatesClassification.htm

Guess it should just be the Classification Name

[dvrvb]

Yes, but I mean, I'm wondering if that attribute should be used in the viewer, because the attribute at # 156 is also the name of the classification.
In other words, I would not be surprised that Solibri used for years the wrong internal mapping. For instance the property "Type" is just in a few cases the name of the TypeClass, but in most cases it is an internal mapping of the "reference".

[HenkMolhoek]

When I load the ifc in navisworks I see the same result as in Solibri, BIM Vision and our own ifc viewer.
We also see a change in notepad++ compared to the previous exporters.

It remains strange that if several reports have already been made, this is denied.
I expected such a major problem to be resolved quickly.

[dvrvb]

https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/lexical/IfcRelAssociatesClassification.htm

Guess it should just be the Classification Name

Yes there is a change in the code, and yes probably the number shouldn't be there. But this is an optional attribute, and probably the viewers should not be using this attribute.

In my opinion the viewers should use this one as most of them do now (but I can be wrong).

So it looks like that thanks to the change of code in the Revit IFC exporter, an old Solibri bug is revealed (and also in some other viewers).

[AngelVelezSosa]

OK, yes, this seems by design then. It should be OK to have a IfcRelAssociatesClassification name, and that is not the IfcClassification name, nor should it be used as such. Probably no one set it before, and we do now (I don't remember why, but perhaps related to the consistent GUIDs work). If my understanding is not correct, please reopen.

[louistrue]

I have a different opinion: #546 (comment)

Why not just leave it empty?