Menu
▾
▴
#15 IfcRelAssignsToGroup not working multiple assignments
The system seems to have problems treating multiple IfcRelAssignsToGroup, particularly when the RelatingGroup is the same.
In a scenario like
#1 = IfcSpace
#2 = IfcSpace
#3 = IfcZone
#4 = IfcRelAssignsToGroup (#1) #3
#5 = IfcRelAssignsToGroup (#2) #3
the sentence #5 is misprocessed, but I have the impression it's not always the first assignment that is kept.
The sentence is not just lost because the output shows things like:
#118781= IFCRELASSIGNSTOGROUP('pmartini00000000000050',#118706,$,$,(#118776),.PRODUCT.,$);
with the RelatingGroup null, which is not valid. Of course, also the XML output is affected.
Files on http://demo.bimserver.org/project.jsp?id=147
Thanks,
Paolo Martini
pmartini at cisco.com
Hi Paolo,
Would it be possible for you to attach the original IFC file, that would make debugging it a lot easier.
Thanks, Ruben
ISO-10303-21;
HEADER;
FILE_DESCRIPTION (('Bimserver.org 0.2RC1 generated IFC file'), '2;1');
FILE_NAME ('grouping.1', '2009-09-02T18:52:30', ('Paolo Martini'), (''), 'Bimserver.org 0.2RC1', '', 'Paolo Martini');
FILE_SCHEMA (('IFC2X3'));
ENDSEC;
DATA;
#26785426= IFCCARTESIANPOINT((0.,0.,0.));
#26785430= IFCDIRECTION((1.,0.,0.));
#26785434= IFCDIRECTION((0.,0.,1.));
#26785438= IFCAXIS2PLACEMENT3D(#26785426,#26785434,#26785430);
#26785439= IFCRELASSIGNSTOGROUP('pmartini00000000000030',#26785441,$,$,(#26785456,#26785461),.PRODUCT.,#26785534);
#26785441= IFCOWNERHISTORY(#26785442,#26785451,$,.NOCHANGE.,$,$,$,1246293006);
#26785442= IFCPERSONANDORGANIZATION(#26785443,#26785447,$);
#26785443= IFCPERSON('','','',$,$,$,$,$);
#26785447= IFCORGANIZATION('','pm','',$,$);
#26785451= IFCAPPLICATION(#26785447,'6.0.56.0','manual','8004');
#26785456= IFCSPACE('pmartini00000000000003',#26785441,'space3',$,$,$,$,$,.ELEMENT.,.INTERNAL.,$);
#26785459= IFCRELASSIGNSTOGROUP('pmartini00000000000060',#26785441,$,$,(#26785456,#26785461),.PRODUCT.,#26785531);
#26785461= IFCSPACE('pmartini00000000000004',#26785441,'space4',$,$,$,$,$,.ELEMENT.,.INTERNAL.,$);
#26785464= IFCRELAGGREGATES('pmartini00000000000005',#26785441,$,$,#26785466,(#26785511,#26785518,#26785456,#26785461));
#26785466= IFCPROJECT('2814IOwMv8Xe$UgOlbMaoX',#26785441,'CISCO','','','whatever',$,(#26785472,#26785476),#26785493);
#26785472= IFCGEOMETRICREPRESENTATIONCONTEXT($,'MODEL',3,1.E-005,#26785438,$);
#26785476= IFCGEOMETRICREPRESENTATIONCONTEXT($,'PLAN',3,1.E-005,#26785480,$);
#26785480= IFCAXIS2PLACEMENT3D(#26785481,#26785485,#26785489);
#26785481= IFCCARTESIANPOINT((0.,0.,0.));
#26785485= IFCDIRECTION((0.,0.,1.));
#26785489= IFCDIRECTION((1.,0.,0.));
#26785493= IFCUNITASSIGNMENT((#26785494,#26785495,#26785496,#26785497,#26785510));
#26785494= IFCSIUNIT($,.LENGTHUNIT.,.MILLI.,.METRE.);
#26785495= IFCSIUNIT($,.AREAUNIT.,$,.SQUARE_METRE.);
#26785496= IFCSIUNIT($,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#26785497= IFCCONVERSIONBASEDUNIT(#26785498,.PLANEANGLEUNIT.,'degree',#26785507);
#26785498= IFCDIMENSIONALEXPONENTS(0,0,0,0,0,0,0);
#26785507= IFCMEASUREWITHUNIT(IFCREAL(0.0174532925199433),#26785509);
#26785509= IFCSIUNIT($,.PLANEANGLEUNIT.,$,.RADIAN.);
#26785510= IFCSIUNIT($,.TIMEUNIT.,$,.SECOND.);
#26785511= IFCSPACE('pmartini0000000000001',#26785441,'space1',$,$,$,$,$,.ELEMENT.,.INTERNAL.,$);
#26785514= IFCRELASSIGNSTOGROUP('pmartini00000000000020',#26785441,$,$,(#26785511),.PRODUCT.,$);
#26785516= IFCRELASSIGNSTOGROUP('pmartini00000000000050',#26785441,$,$,(#26785511),.PRODUCT.,$);
#26785518= IFCSPACE('pmartini0000000000002',#26785441,'space2',$,$,$,$,$,.ELEMENT.,.INTERNAL.,$);
#26785521= IFCRELASSIGNSTOGROUP('pmartini00000000000020',#26785441,$,$,(#26785518),.PRODUCT.,#26785523);
#26785523= IFCZONE('pmartini00000000000011',#26785441,'zone1',$,$);
#26785526= IFCRELASSIGNSTOGROUP('pmartini00000000000051',#26785441,$,$,(#26785518),.PRODUCT.,#26785528);
#26785528= IFCGROUP('pmartini00000000000041',#26785441,'group1',$,$);
#26785531= IFCGROUP('pmartini00000000000042',#26785441,'group2',$,$);
#26785534= IFCZONE('pmartini00000000000012',#26785441,'zone2',$,$);
ENDSEC;
END-ISO-10303-21;
The original
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView,QuantityTakeOffAddOnView,SpaceBoundary1stLevelAddOnView]'),'2;1');
FILE_NAME('SSPdemo.ifc','2009-06-29T18:30:15',('pmartini'),('v',''),'manual','manual','');
FILE_SCHEMA(('IFC2X3'));
ENDSEC;
DATA;
#25=IFCPROJECT('2814IOwMv8Xe$UgOlbMaoX',#24,'CISCO','','','whatever',$,(#5,#10),#19);
#24=IFCOWNERHISTORY(#23,#21,$,.NOCHANGE.,$,$,$,1246293006);
#23=IFCPERSONANDORGANIZATION(#22,#20,$);
#22=IFCPERSON('','','',$,$,$,$,$);
#21=IFCAPPLICATION(#20,'6.0.56.0','manual','8004');
#20=IFCORGANIZATION('','pm','',$,$);
#5=IFCGEOMETRICREPRESENTATIONCONTEXT($,'MODEL',3,1.E-005,#4,$);
#4=IFCAXIS2PLACEMENT3D(#1,#3,#2);
#1=IFCCARTESIANPOINT((0.,0.,0.));
#2=IFCDIRECTION((1.,0.,0.));
#3=IFCDIRECTION((0.,0.,1.));
#10=IFCGEOMETRICREPRESENTATIONCONTEXT($,'PLAN',3,1.E-005,#9,$);
#9=IFCAXIS2PLACEMENT3D(#6,#8,#7);
#6=IFCCARTESIANPOINT((0.,0.,0.));
#7=IFCDIRECTION((1.,0.,0.));
#8=IFCDIRECTION((0.,0.,1.));
#19=IFCUNITASSIGNMENT((#11,#12,#13,#17,#18));
#11=IFCSIUNIT(*,.LENGTHUNIT.,.MILLI.,.METRE.);
#12=IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#13=IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#15=IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);
#17=IFCCONVERSIONBASEDUNIT(#14,.PLANEANGLEUNIT.,'degree',#16);
#14=IFCDIMENSIONALEXPONENTS(0,0,0,0,0,0,0);
#16=IFCMEASUREWITHUNIT(IFCREAL(0.0174532925199433),#15);
#18=IFCSIUNIT(*,.TIMEUNIT.,$,.SECOND.);
#1000001=IFCSPACE('pmartini0000000000001',#24,'space1',$,$,$,$,$,.ELEMENT.,.INTERNAL.,$);
#1000002=IFCSPACE('pmartini0000000000002',#24,'space2',$,$,$,$,$,.ELEMENT.,.INTERNAL.,$);
#1000003=IFCSPACE('pmartini00000000000003',#24,'space3',$,$,$,$,$,.ELEMENT.,.INTERNAL.,$);
#1000004=IFCSPACE('pmartini00000000000004',#24,'space4',$,$,$,$,$,.ELEMENT.,.INTERNAL.,$);
#1000005=IFCRELAGGREGATES('pmartini00000000000005',#24,$,$,#25,(#1000001,#1000002,#1000003,#1000004));
#1000011=IFCZONE('pmartini00000000000011',#24,'zone1',$,$);
#1000012=IFCZONE('pmartini00000000000012',#24,'zone2',$,$);
#1000020=IFCRELASSIGNSTOGROUP('pmartini00000000000020',#24,$,$,(#1000001),.PRODUCT.,#1000011);
#1000021=IFCRELASSIGNSTOGROUP('pmartini00000000000020',#24,$,$,(#1000002),.PRODUCT.,#1000011);
#1000030=IFCRELASSIGNSTOGROUP('pmartini00000000000030',#24,$,$,(#1000003,#1000004),.PRODUCT.,#1000012);
#1000041=IFCGROUP('pmartini00000000000041',#24,'group1',$,$);
#1000042=IFCGROUP('pmartini00000000000042',#24,'group2',$,$);
#1000050=IFCRELASSIGNSTOGROUP('pmartini00000000000050',#24,$,$,(#1000001),.PRODUCT.,#1000041);
#1000051=IFCRELASSIGNSTOGROUP('pmartini00000000000051',#24,$,$,(#1000002),.PRODUCT.,#1000041);
#1000060=IFCRELASSIGNSTOGROUP('pmartini00000000000060',#24,$,$,(#1000003,#1000004),.PRODUCT.,#1000042);
ENDSEC;
END-ISO-10303-21;
Hi Paolo,
I have looked at your example. I can reproduce the same results, but I don't think this is a bug in the software.
'IfcRelAssignsToGroup' has a relation called 'RelatingGroup' which is not an aggregate relation. IfcZone has an inverse relation 'IsGroupedBy', which is also not an aggregate relation. This relation is the inverse of 'RelatingGroup'.
So when you have multiple 'IfcRelAssignsToGroup' objets, referring to the same IfcZone, through 'RelatingGroup', you are describing something that cannot not be stored in the model (the RelatingGroup can only 'remember' one IfcRelAssignsToGroup object).
I do however think the IfcParser should at least give a warning, or even stop with errors, and not produce unpredictable results like it is now, I will look into that later and keep this bugtracker-item open.
I hope to hear from you, especially when you think I am wrong about this.
Regards, Ruben
Hallo Ruben,
sorry for the delay.
The RelatingGroup in IfcRelAssignsToGroup is mandatory, so the null value $ looks really buggy to me.
About the multiple IfcRelAssignsToGroup with the same IfcGroup, I do not agree with your interpretation.
IFC is not meant for internal representation but for information exchange: I do not see anything mandating
a single IfcRelAssignsToGroup for a single IfcGroup and I honestly think that would be a heavy limitation.
The behavior I expect is that the multiple assignments are consolidated, if necessary, in the internal representation
according to simple Predicate Logic. In such case, the inverse relationship, which is only inferred, would have
no problems in expressing all the assignments together or, again, split in sentencies if it want to keep the metadata like
the owner history.
Thanks,
paolo
Dear Paolo and Ruben,
I agree to Ruben that each IfcGroup can only having (even must have exactly) one IfcRelAssignsToGroup refering to it via argument 'RelatingGroup' of IfcRelAssignsToGroup. I can imagine people find this ackward, but this is really an issue for the MSG (Model Support Group of IFC) and it could be send as an issue to their database (see also <http://iai-tech.org/>). The schema defines that this is a requirement for IFC files (for as far as I can see it).
However I also agree with Paolo that an output from the server creating an IfcRelAssignsToGroup with an empty argument 'RelatingGroup' is incorrect also.
I think in short I would say that Ruben in right in saying the input IFC file is incorrect. However the server has to be able to handle such situations because we cannot expect all IFC files are correct (this is maybe even an understatement), already giving feedback that the file is incorrect is ok behavior for the server in my perception. Personally I should even argue if not a server should be able to parse such 'small' errors in a file and generate the files containing the same issues but maybe including a warning. However this last point is just a sense of taste.
@Ruben: you also asked me how I solved this in the IFC Engine DLL, this DLL is less focussed on the schema and will just parse, store and write such files. I will automatically override the schema when it finds such issues to be able to parse all files, even when they contain errors looking at the letter of the schema
Best regards,
Peter.