aothms
commented
3 years ago IfcCartesianPointList3D could also be reencoded as an IfcMatrix<3, N> for example. Maybe even IfcAxisPlacementND and IfcCartesianTransformOperatorND. Maybe even IfcCartesianPoint itself. As such the basic linear algebra in the schema would be much more self contained and portable in standard implementations such as numpy and Eigen.
The examples for nested lists in IfcXML are still buggy was well btw https://forums.buildingsmart.org/t/xml-serialization-of-list-of-lists/237
NB one complicating factor in this is that point is affected by length unit and direction isn't, although we might as well remove units from representation item and make it only affect semantics in pset values.
Description of the proposal: @aothms and I were chatting about the challenges of mapping EXPRESS list-of-lists types to/from UML (e.g., the control point list in IfcBSplineSurface). I've also run into this problem in writing ANTLR parsers for IFC-STP. To reduce dependence on Part 21-specific semantics and improve the consistency of the IFC data model, why not define a new Entity type, IfcMatrix, that allows for the definition of rectangular matrices of arbitrary but finite degree? It would replace (possibly nested) Lists in IFC parameters instead with a reference to an IfcMatrix that contains its contents.
At minimum, IfcMatrix would have three attributes:
This would work like numpy or APL's reshape operator. It might also be a compact way of serializing sensor data, point clouds, or basic linear algebra transformations.
Describe how it contributes to the objectives:
List-of-list semantics are part of ISO 10303. If instead we make provisions for nested (rectangular) lists part of the IFC data model, the schema becomes more self-describing.
Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one): Add
What do we win: The ability to define matrices of arbitrary (finite) degree containing one type of IFC value. This can be used for lists, nested lists, matrix transformations, sensor data, or point clouds, depending on the use case. It also reduces dependency on ISO 10303-specific semantics.
What do we lose This approach doesn't resolve cases with lists-of-lists are used to capture non-rectangular data. How many of examples of that are there in the schema? Where are they?
Schema impact: Parameter type change for all IFC classes using nested-lists. Optionally, we could replace ISO-10303 lists too.
Instance model impact: Serializers would need to rewrite nested lists as IfcMatrix instances. Propose we write a small stub service that does this conversion automatically for existing IFC instance populations to give vendors more time to make necessary changes.
Backwards compatible: No.
Automatic migration possible: I think so. We can detect - in both the schema and the instances - any presence of a (nested) list. If we can guarantee those lists are always rectangular, we can write a tool to automatically generate the equivalent IfcMatrix. Because no data is lost, the migration is reversible too.
Note that not all points need to be satisfied! Backwards compatibility and file size are not concerns.