New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IfcCurveSegment #819
Comments
Positive sense of parametrisation matches the positive direction of |
@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. |
@RickBrice you can see that clearly the segment has to be cut with a negative
|
@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. |
@RickBrice it is just that the statement was not precise enough. The 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 ( The agreement could be that the |
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):
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. |
@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. |
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. |
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). This opens the discussion whether |
SegmentLength only 'recently' changed from |
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. |
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. |
@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. |
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
What does "bound to" mean here?
The text was updated successfully, but these errors were encountered: