buildingSMART Forums

Clarification of IfcSurfaceOfRevolution and IfcArbitary

Hello, could someone please clarify an issue I have come across with some data exported from Revit.

It concerns the use of IfcSurfaceOfRevolution and IfcArbitraryClosedProfileDef. According to the spec:
IfcArbitraryClosedProfileDef can only be 2D geometry (as stated by WR1).

However, the following snippet is present in more than one file within some test data I am running.

#7775= IFCCARTESIANPOINT((926.500000000021,497.500000001911,1050.));
#7956= IFCAXIS1PLACEMENT(#7775,#16);
#7957= IFCCARTESIANPOINT((926.500000000021,448.500000001911,1029.52413241764));
#7959= IFCDIRECTION((0.,0.374606593415917,-0.927183854566785));
#7961= IFCVECTOR(#7959,304.8);
#7962= IFCLINE(#7957,#7961);
#7963= IFCCARTESIANPOINT((926.500000000021,450.327868147789,1025.));
#7965= IFCTRIMMEDCURVE(#7962,(#7957),(#7963),.T.,.CARTESIAN.);
#7968= IFCARBITRARYCLOSEDPROFILEDEF(.CURVE.,‘Revolved Face Profile Curve’,#7965);
#7969= IFCSURFACEOFREVOLUTION(#7968,$,#7956);

Clearly, IfcArbitraryClosedProfileDef uses a trimmed curve which is ultimately a line segment using 2 cartesian points of dimensionality 3.

Is there a special case for IfcArbitraryClosedProfileDef when used within the context of an IfcSurfaceOfRevolution allowing dimensionality 3, or is this incorrect?

The line is obviously representable in 2D by projecting onto the YZ plane, however this would subsequently have a bearing on the placement used (and this would need to be checked and enforced), in which case does this need to be incorporated into the final geometry or should this profile ideally be represented as 2D cartesian points in the first place?

Is the WR1 proposition implied, even though the geometry is explicitly 3D?


Your interpretation is correct I think. There isn’t any magic here the part is simply not valid. An additional issue is the the OuterCurve of the IfcArbitraryClosedProfileDef is not closed, as it is a line segment. I think this is pretty typical for the state we are in with IFC, we don’t have great tooling openly available to automatically validate the rules and constraints. On the other hand we have some rather permissive viewers that try to accommodate invalid files (sometimes on purpose by implementing work-arounds, sometimes by accident when strictly following the rule is actually more work to implement). So quite a few of these issues go undetected. Tagging @angel.velez or maybe better report here with some steps to reproduce.

1 Like