Polyline edit functions

What I mean is that Arcs don’t have ending points as a property/atribute/menber:

Like Lines do:

Meaning that any endpoint of an RLine (or a polyline node for that matter) has a well defined X/Y position in the plane.
While the endpoints of an Arc is a mathematical result, the closest definable X/Y position.
getStartPoint(): qcad/src/core/math/RArc.cpp at master · qcad/qcad · GitHub
getEndPoint(): qcad/src/core/math/RArc.cpp at master · qcad/qcad · GitHub
getPointAtAngle(a): qcad/src/core/math/RArc.cpp at master · qcad/qcad · GitHub

It will be rather precise near the origin, near (0,0;0,0), but decreases in accuracy when further off because of the limited number system.
Polar to Cartesian use trigonometry, RArc to bulge or reverse uses tan()/atan().
The distance between two points is by the hypotenuse what uses sqrt().
Internally rads are used and the accuracy for PI is great but limited.

..
.

It matters but that is not the sole or main issue here.
Matching an RLine start point is within 1e-6 in all directions.
Matching an RArc end is within 1e-9 rads and the amount of 1 radius away from the center within +/-1e-9
=> The tolerance for an RArc endpoint grows with the radius.
And to avoid issues I have seen the use of tolerances up to 1e-3 in standard resources.
It might be a fix in most cases but in the end tolerances should be relative to how accurate it can be.

As example:
RPolyline.appendShape() and all that rely on this: qcad/src/core/math/RPolyline.cpp at master · qcad/qcad · GitHub
When joining an RArc to an RPolyline :

  • The RArc start point if verified against the last node.
  • If the match is within 1e-3 then the RArc endpoint is the new ending node.
  • The bulging factor is calculated of the RArc … As is.
    The issue is now that it is uncertain if the distance between the nodes equals the originally chord …
    … but the bulge is calculated from the original sweep and the bulging factor is an exponential value.

It is thus possible to construct a polyline where the intersection of 2 neighboring Arc-segments doesn’t match with the node in between.
And when you then expect the node to be the intersection then … :wink:

Regards,
CVH