Ifcopenshell: IFC4x3 support?

[Moult]

Just curious what the process is to start supporting the IFC4x3 entities? There's a lot of good infrastructure additions.

[aothms]

Is there a public version? I have some, but not sure if I can publish them.
Only downside is that compilation time is more or less linear with amount
of schemas. 0.7.0 addresses that. And alignment geometry from 4x1 is not
even implemented yet :(

Sent from a mobile device. Excuse my brevity. Kind regards, Thomas

Op di 5 mei 2020 00:09 schreef Dion Moult [e-mail]:

Just curious what the process is to start supporting the IFC4x3 entities?
There's a lot of good infrastructure additions.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/IfcOpenShell/IfcOpenShell/issues/842, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAILWV3HTHXL25KLAYIAVWDRP44LJANCNFSM4MZD46WQ
.

[Moult]

It was released a week or so ago :)

https://standards.buildingsmart.org//IFC/DEV/IFC4_3/RC1/HTML

Alignment geometry is one of the fun ones :) When you say alignment geometry isn't implemented, do you mean it isn't parsed to be faceted? If so, that's OK - because they are highly parametric, and should actually not be converted into a faceted curve if possible.

[aothms]

Alignment geometry is one of the fun ones :) When you say alignment geometry isn't implemented, do you mean it isn't parsed to be faceted? If so, that's OK - because they are highly parametric, and should actually not be converted into a faceted curve if possible.

Can you elaborate on that? Ideally we'd convert them into some sort of OCCT BRep / Wire / Curve / Adaptor. Some of the components are not implemented in OCCT though such as clothoid and the other transitioning curves. What other approaches exist besides faceting? I looked around and couldn't find a quick and easy conversion from clothoid to nurbs for example. If you know someone who would like to take a stab at this for example would be great https://www.sciencedirect.com/science/article/pii/S0377042704000135

[Moult]

@aothms oh sorry, I didn't phrase that quite right - I meant that even if IfcOpenShell could facet it - as I am building the BlenderBIM Add-on to be an authoring package too, I will likely have to parse each alignment segment separately, so that I can re-export it out of Blender with specific parameters changed and retain its full description. The faceted curve is good for visualisation, but not sufficient for full authoring, which is what I'm doing :)

[aothms]

Ok, but for visualization you still need something faceted. And the higher upstream it is implemented the better I guess (i.e. IfcOpenShell C++). But feel free to begin implementing things and we can later move things to C++ also if needed.

I added the 4x3. Keep in mind the schema identifier is IFC4X3_RC1, in case you want to create a new file.

[civilx64]

I'd be willing to help with this as IFC for infrastructure has enormous potential in the transportation industry. I read the abstract of the paper regarding clothoid approximation with NURBS. While interesting academically, I don't see it as a necessity. Faceted alignment geometry has worked well in practice for many years, and NURBS are typically not supported by construction equipment machine guidance hardware or GIS asset management systems.

If I were to take a go at this, where would I start? I would assume this would involve collecting some sample alignment data, parsing the file in python, and developing code to generate the corresponding OCC data structures. Conversion of say a clothoid to a wire would happen behind the scenes in order to get displayable edges and vertices in Blender but would not actually be written to IFC as cartesian points and polylines... correct?

[aothms]

Wow, thanks for your interest in helping. So, the end goal is to have this in C++ next to the other conversion functions, e.g polyline is here https://github.com/IfcOpenBot/IfcOpenShell/blob/v0.6.0/src/ifcgeom/IfcGeomWires.cpp#L616 But if Python is quicker to develop in for you, I don't mind to port things to C++. They don't have to be converted to IFC entities, although it would be interesting to have that as general functionality for viewers that do not support viewing alignments (we have functionality to write OCCT shapes to IFC)

I agree continuous alignment geometry is not a necessity, but it might match Open Cascade's data model better. A student of mine worked on an implementation in Python (https://research.tue.nl/files/46934966/846842-1.pdf) and created a curve from the horizontal alignment, surface of linear extrusion through the horizontal alignment curve and then the 2d vertical curve and extruded surface are the input of a OCCT Edge. It worked pretty seemlessly, but he only used I think linear curves. I don't know if this approach can be extended to the other curves and transitioning curves. This is also not tested when sweeping road profiles, nor tested with cant. So maybe a tesselated approach is best as we have guarantees it will work.

[civilx64]

Yes, I would be much more proficient in Python. I'll review the cpp link you provided and try to match the approach generally so as to make it easier to port to C++.

[civilx64]

I have started implementing alignment transition geometry on a feature branch. I am focusing solely on the 2D horizontal domain to start. My current approach is to calculate points along the curves in local coordinates, then apply matrix transforms to properly locate the geometry relative to start point and direction. We'll see how well that plays out in reality. A few notes:

• I am planning to include the start and end points of the transition curve in the wire. My assumption is that the code parsing the alignment as a whole will recognize and eliminate duplicate points when building the geometry for the entire alignment. This would cover situations where an alignment starts or ends with a transition, versus the typical expected arrangement of a transition between two other segments.

• Similarly, I am not planning to implement any checking for continuity of curvature at the begin or end of the transition segment, but rather leaving that as potential implementation within the context of the alignment as a whole.

Feedback is appreciated, as well as any sample data you or the rest of the community might have for transition types other than clothoids.

[aothms]

@civilx64 very cool!

I am planning to include the start and end points of the transition curve in the wire

That's also what I do in my CGAL (polygonal) implementation for normal ifc2x3 composite curves. So that's great. In C++ OCCT we also have a function for removing duplicate points in general https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.6.0/src/ifcgeom/IfcGeomFunctions.cpp#L1625

Similarly, I am not planning to implement any checking for continuity of curvature at the begin or end of the transition segment, but rather leaving that as potential implementation within the context of the alignment as a whole.

That sounds reasonable.

I'll ask around for some sample files.

[aothms]

@civilx64 can you contact me on [email protected] regarding the sample files?