Closed civilx64 closed 6 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:
Added to validation rules backlog as ALS011, being tracked at buildingSMART/ifc-gherkin-rules#129
closing this one, due to the validation rule's one. Good catch
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?
✓
noRequire documentation changes?
✓
don't knowRule required
✓
normative check: every IFC file must pass this checkAt 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 typeIfcSegment
.Additional context
IfcCompositeCurve
can technically be composed from segments of typeIfcSegment
andIfcCompositeCurveSegment
.Per CT 4.1.7.1.1,
IfcCurveSegment
appears to be the only valid type to be used for the.Segment
property ofIfcCompositeCurve
and subtypes when used for representation of alignments,Subtypes of
IfcCompositeCurve
areIfcSegmentedReferenceCurve
,IfcGradientCurve
, andIfcCompositeCurveOnSurface
.IFC 4.0.2 requires
IfcCompositeCurve.Segment
to be of typeIfcCompositeCurveSegment
. Is the change in IFC 4.3 intentional?I'm guessing a bit on audience targeting but suspect that @aothms, @evandroAlfieri, and @peterrdf are a good place to start.