IfcNonNegativeLengthMeasure not is castable to IfcLengthMeasure

[andyward]

IfcNonNegativeLengthMeasure is defined as being of type IfcLengthMeasure which is itself an Express REAL type.

We implement IfcMeasures as value types (i.e. structs not classes). As a struct means they cannot derive from a class, only implement interfaces.

The issue this raises is that for 'derived' measures such as IfcNonNegativeLengthMeasure - which are backed by IfcLengthMeasure in the spec, (rather than a native Real/Double) - we cannot treat the NonNegative measure as a IfcLengthMeasure without special treatment, because IfcNonNegativeLengthMeasure is not a subclass of the base type.

A good example of the problem this creates is in Ifc4.3's IfcCurveSegment, where SegmentStart & SegmentLength are backed by IfcCurveMeasureSelect but have an informal proposition that only IfcLengthMeasure's should be used (not IfcParameterValue). However that will often include IfcNonNegativeLengthMeasure but a naïve type check will not be treat them as equivalent. Consequently implementing that rule will incorrectly treat NonNegative measures as invalid.

A secondary issue is that Selects such as IfcCurveMeasureSelect don't then include derived measures. The result of this is we can't parse an IfcCurveSegment using an IfcNonNegativeLengthMeasure

One solution for the first issue would be to implement a IIfcLengthMeasure that IfcLengthMeasure and all derived measures can implement - similar to how we implement Express Selects.

[andyward]

Have addressed the immediate issue but there may be other scenarios. E.g. 'derived' measures or other Selects that reference sub-classes.

[andyward]

A broader issue is we cannot use Measures in a schema agnostic fashion since we don't provide a cross-schema interface for them. E.g. while this is now addressed for IfcLengthMeasures, IIfc4x3.MeasureResource.IfcLabel cannot be used in place of Ifc4.MeasureResource.IfcLabel.

See xBimTeam/XbimGeometry#521 and https://github.com/xBimTeam/XbimGeometry/blob/2707aeef3ce710314bc4860ea25324761e616e80/Xbim.Geometry.Engine/Factories/SurfaceFactory.cpp#L175

[martin1cerny]

IfcLabels will convert between the schemas correctly. But I agree, we need to enhance the code generation process to handle Express TYPE inheritance. Best solution will be to introduce new select types which will cover this and will work across schemas.