Polyline refuses distance evaluation though its arc length is an exact sum

[GeneralPawz]

DistanceConvention::Unsupported currently covers three curve families, and one of them does not belong there: a polyline has an exact closed-form arc length, unlike an ellipse or a B-spline.

What refuses today

let curve = Curve3::Polyline(Polyline3 {
    points: vec![
        Point3::new(0.0, 0.0, 0.0),
        Point3::new(3.0, 4.0, 0.0),   // 5 m
        Point3::new(3.0, 4.0, 12.0),  // 12 m
    ],
    closed: false,
});

ev.distance_convention(&curve);          // Unsupported
ev.point_at(&curve, CurveMeasure::Distance(5.0));
// Err(Unsupported { backend: "axiolid-evaluate", operation: CurveEvaluation })

The answer at 5 m is exactly (3, 4, 0). No integral, no iteration.

Why the three families are not alike

The shipped rationale groups them together:

Ellipse, BSpline and Polyline have no closed-form arc length (the ellipse needs an elliptic integral), so distance is refused rather than approximated behind an exact-looking signature.

That is right for two of them and wrong for the third.

Family	Arc length	Cost
Ellipse	incomplete elliptic integral of the second kind	genuinely transcendental
BSpline	no closed form; needs quadrature + numeric inversion	genuinely iterative
Polyline	finite sum of segment lengths	exact, O(n)

A polyline is an ordered point list. Locating a distance is a running sum until the interval is found, then one linear interpolation. Every operation is already exact in Scalar; the only transcendental is the sqrt in each segment length, which Line already relies on and reports as ArcLength3d.

The inconsistency is visible within the current table: Curve3::Line reports ArcLength3d via d / |direction|. A polyline is a sequence of lines. Refusing the sequence while accepting each element is hard to justify from exactness.

Why it matters downstream

IFC4x3 allows IfcLinearPlacement.PlacementRelTo to be any IfcCurve, not only an alignment centreline. IfcPolyline and IfcIndexedPolyCurve are common as basis curves for simple linear referencing -- a kerb line, a fence run, a utility trace -- where nobody authored a full horizontal/vertical alignment.

For those we currently refuse by type rather than place the product, and the refusal is not a statement about the file: the geometry is exactly locatable, the capability is just declared absent.

Ellipse and BSpline we are happy to keep refusing. Neither appears as an alignment basis curve in practice, and an approximation there would be a worse answer than a refusal.

Suggested shape

Polyline reports ArcLength3d and is evaluable by distance. No new enum variant, no trait change, no change for existing callers -- a family moves out of Unsupported.

Three edges worth pinning, because each has a wrong answer that looks plausible:

• A seam is ambiguous. At a vertex the tangent is two-valued. Picking the outgoing segment is defensible; leaving it undefined is not. frame_at at a seam has the same question, and it matters more there, because a sign at a kink would silently take one of two headings.
• Degenerate segments. Repeated identical points give a zero-length segment and a zero tangent. Skipping them changes the parameterisation; refusing is cleaner than normalising a zero vector.
• closed: true. The wrap segment from last point back to first is real length. Whether distance may exceed the open length, and whether it wraps, should be stated rather than discovered.

What we are NOT asking for

Not arc-length reparameterisation in general. BSpline would need quadrature plus Newton inversion, with tolerance and convergence policy attached -- that is a real design decision with exactness tradeoffs, and it should stay refused until someone has a concrete need. This issue is only the family where the exact answer is a sum.

Our side

ifc-geometry reaches this through CurveEvaluator behind a non-default feature, so nothing is needed from us beyond widening one dispatch arm once the convention changes. Verified against 0.2.1: the contract wiring, the CurveMeasure distinction and the reference-up frame_at all work end to end for the Elevated path.

Happy to take the implementation if you would rather review than write it.

[GeneralPawz]

You were right, and the inconsistency you pointed at was the decisive
argument: Line reports ArcLength3d via d / |direction|, and a
polyline is a sequence of lines. Refusing the sequence while accepting
each element could not be justified from exactness.

Implemented on main.

Verified your example first

d=0.0  -> t=0.000000  point=(0, 0, 0)
d=5.0  -> t=1.000000  point=(3, 4, 0)
d=11.0 -> t=1.500000  point=(3, 4, 6)
d=17.0 -> t=2.000000  point=(3, 4, 12)

d=5 is exactly (3, 4, 0) as you said. No integral, no iteration.
distance_convention now reports ArcLength3d for Polyline;
Ellipse and BSpline keep refusing, for the reasons in your table.

The three edges, pinned as you asked

Seam — outgoing. A distance landing on a vertex reads the outgoing
segment's heading. Measured at the kink in your example:

t=0.999999  tangent=(0.6, 0.8, 0.0)
t=1.000000  tangent=(0.0, 0.0, 1.0)   <- outgoing

Degenerate segments — refused. A repeated point gives a zero-length
segment and a zero tangent. Refused rather than skipped: skipping
silently changes the parameterisation, normalising invents a heading.

Closed — counts, does not lap. The wrap segment is real length and
is included in the total. A distance past the total is refused rather
than wrapped: a caller asking beyond the end is more likely to have a
bug than to want a second lap.

One thing worth reporting

My first attempt at the seam test passed while being worthless. I
mutated <= to < in the running sum expecting the test to fail, and
it did not — because both comparisons produce the same parameter at a
vertex. t lands on the integer either way.

What actually pins the seam is polyline_span's floor, which sends an
integral parameter to the segment starting there. I had written a
comment crediting the comparison, which was simply wrong. Corrected, and
the test now fails when the real mechanism is mutated to resolve a
vertex to the incoming segment.

The other two edges were mutation-verified the same way: accepting
zero-length segments fails the degenerate test, removing the upper bound
fails the closed-polyline test.

Scope

No new enum variant, no trait change, no change for existing callers —
a family moved out of Unsupported, exactly the shape you suggested.
Arc-length reparameterisation in general is untouched; BSpline still
needs quadrature plus Newton inversion with a tolerance and convergence
policy, and that stays refused until someone has a concrete need.

ADR 0063 carries an addendum recording the reversal and the three
conventions, since its original table asserted the grouping you
challenged.

Thanks for the report — the downstream framing (IfcPolyline as a
basis curve for simple linear referencing, where nobody authored a full
alignment) is what made the priority obvious.