IfcCurveSegment

[asf-asf]

I followed the "Is this page difficult to understand? Let us know!" link on https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcCurveSegment.htm

I am having some trouble interpreting the statement

RefDirection is bound to the parametrization sense of the segment.

What does "bound to" mean here?

[aothms]

cc @SergejMuhic @peterrdf @rickbrice

[SergejMuhic]

Positive sense of parametrisation matches the positive direction of RefDirection i. e. the vector RefDirection points in the same direction as the IfcCurveSegment, meaning we do not reparameterise the segment hence no SenseAgreement attribute as on IfcTrimmedCurve.

[RickBrice]

@asf-asf I too find the documentation very confusing. I think it means the positive direction of RefDirection is the same as the positive direction of the curve segment. The positive direction of the curve segment is the tangent to the curve in the start-to-end direction. Since RefDirection is "bounded" to this, if the curve changes then the RefDirection changes as well.

RefDirection is optional, so examining the default value may help. When omitted, RefDirection is (1,0) or (1,0,0) for IfcAxis2Placement2D and IfcAxis2Placement3D, respectively. IfcAxis2Placement3D says RefDirection is taken from the geometric coordinate system, which would be the curve segment coordinate system (e.g. tangent to the curve). IfcAxis2PlacementLinear says explicitly that, when omitted, RefDirection is taken from the curve tangent.

RefDirection is generally the X-axis of a coordinate system (or used to find the X-axis from X cross product Z = Y and Z cross product Y = X). The coordinate system attached to a curve generally has the X-axis as the tangent to the curve.

Maybe I'm incorrect or oversimplifying the discussion. This is how I see it in my mind. I think some pictures in the documentation would be helpful.

[SergejMuhic]

@RickBrice IfcCurveSegment is a segment. It does not have a direction. So, as explained above, the Placement of the IfcCurveSegment does not just provide the Position but also the "starting direction" of parametrisation for the segment in the context of the curve that uses the segment.

In this image:

you can see that clearly the segment has to be cut with a negative SegmentLength as it is in the opposite direction to the IfcCircle parametrisation. Such a cut segment retains the parametrisation of the circle (obviously) since this is the way it was cut. To get the new direction of parametrisation, as I have drawn on the segment to the right, we use RefDirection to avoid having an additional parameter such as IfcTrimmedCurve.SenseAgeement.

RefDirection being optional in the schema has nothing to do with this particular usage of it. Please disregard the optionality in this particular case.

[RickBrice]

@SergejMuhic Thank you for the clarification - images like this would be very helpful in the documentation.

I assumed there was a direction of the segment because, as shown in the image SegmentStart with a negative SegmentLength is counter-clockwise. If a positive SegmentLength is specified it would be clockwise.

[SergejMuhic]

@RickBrice it is just that the statement was not precise enough. The IfcCircle has a parameterisation (with a positive sense) and the curve in which the segment is used has a parameterisation (and a positive sense). Segments do not have a parameterisation, just curves do (due to the nature of their definition).

Initially, segments were not even standalone geometric representation items, they had to be referenced by something. I still do not like this change but it was vigorously requested (IfcShapeRepresentationTypes function has been changed to accommodate RepresentationType='Segment'). Other discussion though, let's not start it here. 😄

The agreement could be that the SegmentLength sign determines the direction of parametrisation since Placement always corresponds with SegmentStart for IfcCircle. For IfcSpiral this does not work anymore because spirals are parameterised from -∞ to ∞. This means you might have cases where you cut the segment from the e. g. third quadrant, SegmentLength therefore being negative but you still want it to be parameterised in the positive sense from SegmentStart. Not sure if this is clear from text. Let me know if I should put together another sketch.

[aothms]

Not sure if this is clear from text. Let me know if I should put together another sketch.

I know from experience and from hearing from others, that exactly the diagram we had on TrimmedCurve with underlying Circle has helped clarify a lot of things. Because it is exhaustive in the possibilities and therefore educational on why things are that way.

The SVG docs have something similar (but they use a different schema):

Source: https://www.w3.org/TR/SVG/paths.html#PathDataEllipticalArcCommands

I think an illustration like that would be tremendously helpful. It doesn't need to be a neat technical drawing, a rough sketch is fine, just so that we capture the knowledge. Others can create a neat technical drawing out of it.

[RickBrice]

@SergejMuhic I do see that the IfcCurveSegment.Placement locates and orients the clipped segment. I still get confused with the relationships between the parent curve placement and curve segment placement, and also parametric curves in general. I learn when smart people correct my posts - thanks.

[TLiebich]

Hi, I had created the drawing, @aothms mentioned, for IfcTrimmedCurve. I attach you the original DWG from 2002 (hope it can still be loaded) in case someone wants to use it as a baseline to explain the parameterization of segments. And yes, this old figure helped a lot during IFC2x3 implementation to get it right. IfcTrimmedCurve_Parameterization.zip - note: I had to zip, since *.dwg is not an allowed format for file attachments

[SergejMuhic]

I had a go with sketching a curve segment on a spiral and realized one thing. Since they are paramterised from -∞ to ∞, SegmentLength sign is already sufficient to determine the sense agreement (corresponding parametrisation to the base curve). Original Euler spiral by By AdiJapan - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=22191870

This opens the discussion whether RefDirection should imply the sense i. e. traversing the base curve in the same direction or SegmentLength takes that responsibility.

[aothms]

SegmentLength sign is already sufficient to determine the sense agreement

This opens the discussion whether RefDirection should imply the sense i. e. traversing the base curve in the same direction or SegmentLength takes that responsibility.

SegmentLength only 'recently' changed from nonnegativelength to length (for the length part of the select, parameter value was already possible to be negative). So maybe it's not surprising that we're having this discussion now. If I may cast a vote as a non-domain expert I'd vote for having the length indicate the direction sense and having the placement operate solely as a positioning operation. This is analogous to how the placement is interpreted e.g in case of the solids, where placement is applied 'last' if you think of it as a sequence of operations and doesn't affect the 'geometric form'.

[RickBrice]

Seems like the "sense" of the trimmed segment is defined by both the Placement and the SegmentLength. SegmentLength defines the direction of trimming relative to SegmentStart and Placement defines the direction of the segment tangent at the start of the segment.

@SergejMuhic is there a good online reference that presents the general concepts of parameterized curves as they relate to IFC? Perhaps having a better understanding will help those that are still new to IFC. The discussion of parameterization seems to be a little moot given the informal proposition.

[SergejMuhic]

SegmentLength sign is already sufficient to determine the sense agreement

This opens the discussion whether RefDirection should imply the sense i. e. traversing the base curve in the same direction or SegmentLength takes that responsibility.

SegmentLength only 'recently' changed from nonnegativelength to length (for the length part of the select, parameter value was already possible to be negative). So maybe it's not surprising that we're having this discussion now. If I may cast a vote as a non-domain expert I'd vote for having the length indicate the direction sense and having the placement operate solely as a positioning operation. This is analogous to how the placement is interpreted e.g in case of the solids, where placement is applied 'last' if you think of it as a sequence of operations and doesn't affect the 'geometric form'.

Correct, the initial concept I developed was with length as a parameter value (exclusively) in mind (which IMHO still makes sense since in IFC the measure feature meaning). Then non negative length measure made it into the mix because testers (two of the three - I was the only one for parameter value exclusively) wanted to work with lengths with all their downsides (=project units). This is something that is not really typical in the part 42 core when moving along curves or parameterising surfaces etc. Hence, I would always opt for parameter value in place of length measure. This also avoids an unnecessary select type ... Makes implementation and rule creation much simpler. Conversion is always present (either units or parameter values) and with more experience the initial testers also agreed that a unitless value makes much more sense but the damage was done and we were stuck with the select. A parametric value also quite elegantly handles extreme lengths which are suddenly reduced to a 1.0 (typically, apart from circular curves such as conics).

@RickBrice yes, that is what happened because the initial definition was changed without considering all the aspects. The implementers forum voted on that.

On the other question, I have not published it yet but I have started writing a paper on the entire curve segment and spiral geometry development. In the current state, it is not ready to publish but maybe I should bring it into a state of "white paper" at least and share before writing a real article.

Certain discussions are problematic. I have put a lot of research and development into these concepts. The ISO publication still features my notes because the project where the templates and usages were supposed to be finalised with the experience from the deployment project was cancelled. A half finished product went to ISO that to my surprise accepted it. Probably nobody even read these parts. But parametrisation plays a huge part in linear referencing which is one of the main domain requirements. How this is supposed to work for actual exchanges if there is no clear definition will be quite interesting. The vacuum left serves only the big companies (as we see what happened with length measure), where a clear mathematical definition is pushed aside for a proprietary implementation in a tool whose vendor has most leverage.

[RickBrice]

@SergejMuhic I've been documenting my journey learning about curve segments and spiral geometry development. Perhaps some it will be useful to your efforts. I'd be happy to look over your work in its current state and share what I have done. We can take this to an offline discussion if you like.

IMHO, the goal is to have high quality data exchanges so obscuring details in confusing technical jargon and making the IFC schema specification difficult to use doesn't serve openBIM community at all.