Open oyo-rdc opened 8 months ago
Updated the file
@pjanck : Seems like a bug in the checker (object reference not set to an instance of an object).
Alright, checked the file and there is a bunch of things wrong with it. The checker expects a certain completeness and since it is not there, we get a null value.
The following should be corrected first as these mistakes are already very deep on schema level: StepSerializer: #27 IfcLocalPlacement attribute PlacementRelTo of type IfcObjectPlacement does not match provided type IfcAxis2Placement3D. StepSerializer: #1002 IfcLocalPlacement attribute PlacementRelTo of type IfcObjectPlacement does not match provided type IfcAxis2Placement3D. StepSerializer: #1002 IfcLocalPlacement attribute RelativePlacement of type IfcAxis2Placement does not match provided type IfcLocalPlacement. StepSerializer: #1012 IfcDerivedUnit attribute Name is required but does not have a value.
The PlacementRelTo
attribute should not point to IfcAxis2Placement
but to another IfcObjectPlacement
. On the other hand, the attribute RelativePlacement
should point to an IfcLocalPlacement
. Apparently the two attributes were switched. PlacementRelTo
should be on position 1 and RelativePlacement
on position 2. This is the case for # 1002.
The last issue for IfcDerivedUnit
is not that critical but Name
is mandatory.
@SergejMuhic, thank you for checking! I'll look into it and correct it.
@SergejMuhic I uploaded the revised file and failed the checker again. Would you please provide where it is wrong? Also, about IfcDerivedUnit, the attribute "Name" seems optional in the IFC4x3 add2 documentation (https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcDerivedUnit.htm), but it seems mandatory in the 4x4 draft documentation. Has it been changed?
@SergejMuhic I uploaded the revised file and failed the checker again. Would you please provide where it is wrong?
We are still dealing with serialization errors on voxel (see inline for further explanation):
StepSerializer: #108 IfcShapeRepresentation attribute ContextOfItems of type IfcRepresentationContext does not match provided type IfcLocalPlacement. -> IfcShapeRepresentation
.ContextOfItems
(first attribute) points to 103 IfcLocalPlacement
. Should point to an IfcRepresentationContext
.
StepSerializer: Object of type 'THC.IFC4X4.IfcRepresentationResource.IfcGeometricRepresentationSubContext' cannot be converted to type 'THC.IFC4X4.IfcGeometryResource.IfcRepresentationItem'.for elements: (#106) -> IfcShapeRepresentation
.Items
points to IfcGeometricRepresentationContext
, should be pointing to IfcRepresentationItem
StepSerializer: #1007 IfcShapeRepresentation attribute ContextOfItems of type IfcRepresentationContext does not match provided type IfcLocalPlacement. -> same error as the first but for 1007.
Also, about IfcDerivedUnit, the attribute "Name" seems optional in the IFC4x3 add2 documentation (https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcDerivedUnit.htm), but it seems mandatory in the 4x4 draft documentation. Has it been changed?
No, you are right. This will be corrected in the reconciliation efforts. This issue does not influence a drop out of the check procedure however, so just ignore for now.
@SergejMuhic Thank you for checking. Clearly my mistakes -- I forgot to update the line numbers. Manual editing is not easy... The corrected file still fails the check. Is there a way I can see error messages from the checker?
@SergejMuhic Thank you for checking. Clearly my mistakes -- I forgot to update the line numbers. Manual editing is not easy... The corrected file still fails the check. Is there a way I can see error messages from the checker?
Two issues:
IFCLABEL('\X2\76db571f0028792b6df73058308a78028cea7c98571f0029\0\ Fill (Sandy clay with gravel)')
the closing encoding is \0\
and should be \X0\
#1015= IFCPROPERTYENUMERATEDVALUE('SurveyMethod',$,(.PASSIVE_SEISMIC.),$);
should be
#1015= IFCPROPERTYENUMERATEDVALUE('SurveyMethod',$,IFCLABEL(.PASSIVE_SEISMIC.),$);
Uploaded a new ifc file (tokyo/tokyo-sections.ifc) that contains a geological section. Currently, it uses IFC4x3 entities (i.e. building element proxy etc.) to view in BIM vision because the file is not rendered correctly in ifcviewer (please see screenshots below). @peterrdf Would be appreciated if you could check the file and look into why this happens. Thank you.
Alright, the file is good. @peterrdf found a small bug. Here the screenshot:
my bad indeed, the bug is fixed, viewer and library will be updated early next week (https://[rdf.bg/product-list/ifc-engine/ifc-viewer/](https://rdf.bg/product-list/ifc-engine/ifc-viewer/))
Thank you, @peterrdf, @SergejMuhic for checking. I'll test our files with the updated version.
File
Containing voxel