Implement IFC Alignment Geometries

[andyward]

Following on from #106, which I think we can close, we've implemented some of the IFC4x1 & IFC Alignment geometries - but not all.

E.g. Martin identified the following as needing implementation. Where checked, we've implemented these to some extent in the ifcRail branch.

• [ ] IfcTriangulatedIrregularNetwork
• [ ] IfcTransitionCurveSegment2D
• [ ] IfcSectionedSolid
• [ ] IfcSectionedSolidHorizontal See XbimTeam/XbimWindowsUI#114
• [ ] IfcOffsetCurveByDistances
• [x] IfcOrientationExpression
• [x] IfcLinearPlacement
• [x] IfcCurveSegment2D
• [x] IfcCircularArcSegment2D
• [x] IfcAlignmentCurve
• [ ] IfcAlignment2DVerticalSegment
• [ ] IfcAlignment2DVertical
• [ ] IfcAlignment2DVerSegParabolicArc
• [ ] IfcAlignment2DVerSegLine
• [ ] IfcAlignment2DVerSegCircularArc
• [ ] IfcAlignment2DSegment
• [x] IfcAlignment2DHorizontalSegment
• [x] IfcAlignment2DHorizontal

[bekraft]

Maybe it makes sense to shift to the IFC4x2 spec which is already in draft mode (see https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/). It adds new usecases for IfcAlignment and therefore testcases to test. To my knowledge IFC4x1 misses the link between IfcProduct and IfcAlignment (IfcRelPositons, see https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/link/ifcrelpositions.htm). On the other Hand IFC4x2 only adds more entities but no new geometrical concepts. An early adoption would help to add better testing (IfcAlignment is more about positioning than about representation). What is your opinion?

[martin1cerny]

In IFC4x1IfcAlignment is IfcProduct.

[bekraft]

Sure. The inheritance of IfcProduct injects some relations (nesting, relative positioning etc.) and an optional representation. But its expressiveness is about horizontal and vertical positioning of other products. The shape of an alignment as product has only a descriptive function. Additionally, there are changes in Ifc4x2 made to the alignment part.

[andyward]

Martin & I discussed this a few days ago. I guess some of it kind of depends on :

1. whether ifc4x2 introduces breaking change on ifc4x1 schema (I think it is?). i.e. does it need a new schema or can we support in Xbim.Ifc4
2. When 4x2 is slated for Release
3. When 5x0 is due out
4. Whether 4x2 gains a lot of support in the authoring tools between 4x2 & 5x0 adoption - or whether they go straight to 5x0
5. How much time people have to do the schema work

Personally I think we should support draft ifc4x2 in develop, for completeness and to help with adoption / testing of the schema. I think we're planning a push of xbim 5.1 to master & nuget in the next few days so maybe think about this for xbim 5.2

[bekraft]

Is there any plan to merge the ifcRail branch into develop (at least the changes of geometry handling)? Is there any tutorial how to run the IFC scheme generation (i.e. for 4x2)?

[martin1cerny]

Current version of the IfcRail implements the pilot version of the schemas. It is still under development and we are supposed to provide reference implementation for the next iteration within a few weeks. We plan to merge this into the main branch once it is a final standard or better - part of IFC5. Before that it might be confusing and might lead to development of solutions incompatible with future versions.

We run the code generation internally because the tooling we use is something we developed in-house for a specific purpose and might fail in general use. Also, there is some portion of manual work involved when new (or changed) schema is generated.