buildingSMART / IFC4.x-IF

IFC4.x Implementers Forum
28 stars 33 forks source link

Consistent type for .Segments attribute of IfcCompositeCurve (and subtypes) #137

Closed civilx64 closed 6 months ago

civilx64 commented 7 months ago

Problem

The IFC 4.3 specification is unclear. See comment in buildingSMART/validate#7 by @RickBrice.

Solution(s)

I believe that a validation rule is required, but I would like to gather consensus on the details of the rule. Also I would need to know if this should be documented as an implementer agreement or informal proposition. (My hunch is the latter.)

Require schema changes?

Require documentation changes?

Rule required

At minimum the validation rule should probably enforce a consistent type for all of the Segments - no mixing or matching. The rule might also enforce the use of type IfcSegment.

Additional context

I'm guessing a bit on audience targeting but suspect that @aothms, @evandroAlfieri, and @peterrdf are a good place to start.

aothms commented 7 months ago

Per CT 4.1.7.1.1, IfcCurveSegment appears to be the only valid type to be used for the .Segment property of IfcCompositeCurve and subtypes when used for representation of alignments,

I think alignment representations as simple polylines is also condoned. from that point of view it would make sense to also allow the regular STEP brother (haha) IfcCompositeCurveSegment for an alignment representation.

I think the following rules make sense:

civilx64 commented 6 months ago

Added to validation rules backlog as ALS011, being tracked at buildingSMART/ifc-gherkin-rules#129

evandroAlfieri commented 6 months ago

closing this one, due to the validation rule's one. Good catch