EPIC: SQL/MM Spatial (ISO/IEC 13249-3) Curve Awareness in JTS

[grootstebozewolf]

Epic: SQL/MM (ISO/IEC 13249-3) Curve Awareness in JTS

AI Disclosure (per the Eclipse Foundation Generative AI Usage Guidelines for Committers)

This document and the companion red-test class
modules/curve/src/test/java/org/locationtech/jts/spec/curveawareness/CurveAwarenessSpecTest.java
were largely AI-generated. The human contributor has reviewed and verified the
technical content (cross-module impact, risk register, phase dependencies, TAG
scope) for correctness. The AI-generated portions are made available under
CC0-1.0 (public domain dedication) and are not subject to the project's
licence; human curation and edits are subject to the JTS dual licence.

SPDX-License-Identifier: (EPL-2.0 OR EDL-1.0) AND CC0-1.0
Assisted-by: xAI Grok (cursor grok-4.6)
Assisted-by: Claude (Opus-4.7)

JTS logo as curves plus a buffer halo. Not a closed-form buffer laser. Not a guide figure.

Status: Draft v6 (2026-08-16).
Source: #7 feature/sfa-curve-rgr @ b2861a08 — SQL-MM types, WKT, WKB 8–12, OverlayNGCurve, TestBuilder logo-as-curves. #8, #10, #11, #35, #42 (has #41), #43, #44, #45, #46, #14, #22, #31, #39 are on #7. Bar 2 / #38 / curve-rgr-bar2-rc0 / #27 stay off #7. Do not merge #7 to locationtech/jts master from a stacked-PR button.
Origin (historical): feature/sfa-curve-buffer-spike — Draft v3 of this epic and the 49-method spec class.
Audience: locationtech/jts maintainers and contributors.

Field contract (PERF-GATE): Maintainable → Reliable → Faster. Take the curve path only if t_laser ≤ 1.15 × t_chainsaw. The 15% slack is not to be loosened. The overlay is named OverlayNGCurve, not Curved.

Vocabulary. A TAG is a short, stable identifier for one unit of work, each with a matching red test in CurveAwarenessSpecTest. A kit is a closed-form implementation covering one specific pairing of geometries. A named miss is a pairing with no kit yet, given an identifier so it is tracked rather than silently linearised. A laser is the closed-form path; the chordsaw (written chainsaw in the PERF-GATE formula above — the two should be reconciled to one word) is the densify-then-operate fallback. Bar 2 is the follow-on delivery bar, the circular noder and arrangement work (OV-P2), tracked outside this epic.

1. Goal

Make JTS preserve the ISO/IEC 13249-3 (SQL/MM Part 3) curve, surface and solid geometries — CIRCULARSTRING, COMPOUNDCURVE, CURVEPOLYGON, MULTICURVE, MULTISURFACE, POLYHEDRALSURFACE, TIN, TRIANGLE, CIRCLE, GEODESICSTRING, ELLIPTICALCURVE, NURBSCURVE, CLOTHOID, SPIRALCURVE, COMPOUNDSURFACE and BREPSOLID — through every algorithm where the math is sound, instead of silently linearising to flat parents on the way in.

jts-curve is no longer only a parse-and-WKT/WKB stand-in: types exist, WKT round-trips without densify and WKB codes 8–12 do too, and OverlayNGCurve takes a closed form when one exists. Every circular pair that has a closed form has a kit. Everything else is a named miss and the chordsaw. We will not write a circular noder in this PR. jts-core still densifies on contact for everything that is not one of those kits. This epic tracks the lift, operation by operation — full TAG vs closed-form subset, not “good enough as linearised”.

2. Why

• Performance. Each densification step expands a typical arc to many chord points (≥50 for a half-circle at 1% chord-tolerance); pipelines that buffer → simplify → union compound the cost.
• Precision. Densify → operate → densify drifts control points by ULPs and breaks snap-to-grid round-trips against SQL/MM producers.
• Interop. PostGIS, Oracle Spatial, NetTopologySuite emit and consume curve geometries; WKB 8–12 now reconstructs the curve and surface subclasses when the factory can. Algorithms that still linearise remain the interop gap.
• Discoverability. TestBuilder can show the JTS wordmark as curves plus a buffer halo (hero). Open-arc / clothoid / compound buffer is still chords. Do not read that halo as a closed-form buffer laser.

3. Scope decisions

In scope (this epic):

• Algorithms operating on the full ISO/IEC 13249-3 extended type set — the curve, surface and solid types — in 2-D and in their Z / M / ZM forms.

• WKT round-trip with member structure (landed on include ora and sde modules #7).

• WKB type codes, as given by ISO/IEC 13249-3 §5.1.68, Table 15. The extended set is 8–12, 15–24 and 102, plus BrepSolid at 1025 (Z only — the standard defines no 2-D BrepSolid, and 1025 is 25 + the Z offset, so slot 25 is spoken for). Codes 13 and 14 are not used by 13249-3; OGC SFA reserves them for the abstract Curve and Surface types. Any range spanning 13 or 14 — including the "8–21" this document used to claim — is wrong.

  Code	Type		Code	Type
  8	CircularString		18	Circle
  9	CompoundCurve		19	GeodesicString
  10	CurvePolygon		20	EllipticalCurve
  11	MultiCurve		21	NURBSCurve
  12	MultiSurface		22	Clothoid
  15	PolyhedralSurface		23	SpiralCurve
  16	TIN		24	CompoundSurface
  17	Triangle		102	AffinePlacement

  Dimension offsets are +1000 (Z), +2000 (M), +3000 (ZM). Separately, and this is a different scheme rather than the dimension offset, Table 15 also allows 1000001–1000005 as alternate codes for CircularString through MultiSurface. The two do not compose: CircularString Z is 1008, not 1000001 + 1000. An earlier draft of this document asserted that the 1000-series was only the dimension offset; both schemes are real.

• Landed so far: 8–12 (on rename to jts-io-common #8, now on include ora and sde modules #7). Core WKBReader takes those five the way GEOS does, delegating construction to GeometryFactory; CurveWKBWriter emits them through a hook placed before the instanceof chain. Core WKBWriter emits none of the extended codes unless that hook or subclass is used. Codes 15–24, 102 and 1025 are in scope and not started.

• TestBuilder rendering and drawing tools.

In scope, sequenced late — the hard parts, named rather than hidden:

• POLYHEDRALSURFACE (15), TIN (16) and BREPSOLID (1025). Structural and drawing support landed in the spike for visualisation; the 3-D semantics have not started.
• ELLIPTICALCURVE (20). JTS has no ellipse model and adding one is the single largest piece of work here. It stays in scope because the epic tracks the whole standard, but nothing earlier should wait on it.

Out of scope:

• Z / M ordinate interpolation across densified arcs. Today they propagate from the control points unchanged; every TAG that produces densified output should leave room for a future interpolation policy.

3.1 Proprietary and encumbered curve forms

SPIRALTYPE is an open value set. 4.2.12 names clothoid, bloss, biquadratic, sine and cosine as the initial set, and §5.1.68 encodes the value as <byte> <letters> — length-prefixed precisely so the set can grow. Some forms that would populate it are encumbered.

The Wiener Bogen is the worked example. It is a transition curve that shapes the alignment around the vehicle's centre of gravity rather than the track centreline, which is what lets it cut lateral acceleration and maintenance cost below what a clothoid achieves. It was invented by Herbert Hasslinger, filed as Austrian application A 1116/2002 on 23 July 2002 (see also EP1523597B1), is held by Wiener Linien and ÖBB, and "Wiener Bogen" has been a registered trademark since 2002.

The scope rule, which costs nothing and requires no licence:

Carry the label, not the math.

• Representation is not implementation. A SPIRALTYPE value is a string. Round-tripping SPIRALCURVE (…, SPIRALTYPE Wiener Bogen) through WKT and WKB stores and returns a name its producer chose. No JTS code computes the curve, so there is no implementation for a claim to read on. This is also why the WKT grammar accepts an arbitrary SPIRALTYPE name rather than a closed enumeration.
• Unknown spiral types are opaque, never approximated. toLinear(tolerance) on a spiral type JTS does not implement must fail with a clear message rather than quietly substituting a clothoid. Substituting is wrong geometry first of all, and it is also the point at which "JTS implements the Wiener Bogen" stops being obviously false.
• Implementations arrive from outside, if at all. A SpiralTypeStrategy SPI would let a party that holds or has licensed the rights register the math in their own deployment. Nothing encumbered ships in the JTS distribution, so the EPL-2.0 patent grant is never asked to convey rights no contributor holds — the specific hazard for permissively licensed code, where a downstream user would otherwise receive an implementation with no accompanying grant.
• The trademark outlives the patent. A patent filed in 2002 runs its 20-year term out around 2022, and anyone relying on that should confirm it for their own jurisdiction rather than take this document's word. A registered mark renews indefinitely. So treat "Wiener Bogen" as a name for a value a producer wrote, never as a product claim, a branded feature, or anything that implies endorsement by the mark's owners.

This is engineering policy, not legal advice, and the epic should not be read as though it were. It is the ordinary line between interface and implementation, applied to a case where getting it wrong is expensive.

4. What's already landed

4.1 On #7 since the spike (tip b2861a08, 16 Aug 2026)

Bucket	Summary	TAG honesty
feat: / fix:	WKB 8–12. Core WKBReader first-class cases: CircularString = count+coords; CompoundCurve / CurvePolygon / MultiCurve / MultiSurface = count + child WKBs (CurvePolygon rings carry their own type). GeometryFactory.createCircularString / createCompoundCurve(LineString[]) / createCurvePolygon(LineString, LineString[]) / createMultiCurve / createMultiSurface — default throws; CurveGeometryFactory implements. new WKBReader(new CurveGeometryFactory()).read(type8) returns CircularString. CurveWKBReader is the no-arg convenience. Locked XDR hex for CIRCULARSTRING (0 0, 5 5, 10 0) unchanged. Disc CurvePolygon area still 25π after round-trip. No toLinear on that path.	WKB sibling from Draft v3 — landed. Not a new public I/O class beyond the factory surface + existing curve writer/reader convenience.
feat:	OverlayNGCurve (OV-P1). Algebra (self/empty) → retention (covers/disjoint) → kits → chordsaw. R1.5 two-disc (crossing lens/blob/crescents and 0-node strict nested annulus, area 16π, covers EEEE / coveredBy EE0E). R1.6 disc vs hole-free plain polygon. R1.7 CompoundCurve shells: two-node clip, two-shell, collinear diameters, 0/1-node, even-n, tangent-odd NSpan, same-outer hole, different-outer punch. R-LL lineal arc vs line. R-AA two CircularStrings at exact nodes. Two-disc matrix is EEEE / EE0E.	OV-P1 flipped. On #7 the leftover named misses are still H-SHELL-N-MIXED, H-SHELL-HOLE-CROSS, H-SHELL-HOLE-X, H-ANNULUS-TANGENT. Stacked drafts (do not merge into #7) sew HOLE-CROSS / HOLE-X / HOLE-OUTER and take a first OverlayNG cell for H-SHELL-N-MIXED. H-ANNULUS-TANGENT stays a named miss. Circular noder + arrangement is OV-P2 / Bar 2, a different epic. Do not mark the full OV TAG green.
feat:	R-CONT certified disc PIP (interior + boundary band) in CurveExact.	R-CONT partial.
feat:	R-PR DE-9IM for disc vs Point, LineString, hole-free Polygon, and two discs. Point: interior 0F2FF1FF2, boundary FF20F1FF2, exterior FF2FF10F2. Line: crossing 1F20F1102, tangent FF20F1102, miss FF2FF1102, endpoint-interior 1020F1102. Polygon: disjoint FF2FF1212, nested 212FF1FF2, disc-in-square 2FF1FF212, crossing 212101212. Two discs: crossing 212101212, disjoint FF2FF1212, nested 212FF1FF2 / 2FF1FF212, ext tangent FF2F01212, int tangent 212F01FF2, equal 2FFF1FFF2. Finish slice: single-member MultiSurface both orders; equalsTopo on equal/crossing/rotated-control discs; full SFS table; crosses of two areas always false. Half-disc / CompoundCurve miss still null → linearise.	R-PR partial. Not “any combination of curved/flat”. Do not delete test_R_PR_* / test_R_CONT_*.
feat:	Distance closed-form helpers in CurveExact (arc-to-segment, overlapping discs nearestPoints 0, decideTolerance arc-aware).	Helpers only. D-PT / D-AA / D-OP still describe the public DistanceOp TAG — keep those spec methods red.
feat:	Disc / single-arc / CompoundCurve convex hull closed forms. CompoundCurve hull is a CurvePolygon (area 61.59119, CircularString shell). Clothoid hull is still a linear POLYGON fallback.	H-CV / H-CC partial. ConcaveHull stays out.
feat:	Public DiscreteHausdorffDistance closed forms for two pairs only (via 0ca71b): CIRCULARSTRING (0 0, 2 3, 10 0) vs LINESTRING (0 0, 10 0) APEX √949/6 − 7/6 ≈ 3.967640600249787; two r=5 discs, centres 0 and 10 → 10.0. Exact path skips densify. Public DHD still sees chords in general. Fréchet still open.	D-HF partial (two pairs). Keep fail(). No new public pair.
feat:	Disc CurvePolygon area 25π.	M-AREA-CP partial (circular discs). Keep the spec method.
feat:	LEC typed obstacle distance (point / segment / polygon / arc / disc). Disc closed form; 3-4-5 pins.	LEC partial. Keep the spec method if the public TAG is wider.
arch:	PERF-GATE: identity/chord-path rows use assertChordPath; slack stays 15% (1.15).	Contract, not a TAG.

These closed-form subsets of OV and R-PR did not wait for N-SS. Line–circle clip is used inside R1.6; there is still no public arc-arc / arc-line utility and no arc SegmentString. That is OV-P2, not a hole in OV-P1.

Still open (say so, do not close as “future work” a TAG that already has a named subset):

• Named overlay miss still stamped: H-ANNULUS-TANGENT
• On include ora and sde modules #7 only (sewn on stacked drafts, not merged): H-SHELL-HOLE-CROSS, H-SHELL-HOLE-X, H-SHELL-HOLE-OUTER; H-SHELL-N-MIXED first OverlayNG cell
• General circular noding (N-AA, N-AL, N-SS) — OV-P2 / Bar 2. Do not start in this PR.
• Open-arc buffer. Clothoid hull is a linear fallback
• OFF = concentric arc (refactor)
• RocqRefRunner SQL/MM suite for public Curve predicates
• TestBuilder inspector ClassCastException (visual QA initial maven module structure #3)
• equalsExact arc-vs-chord (R-EQ)
• Most of Phase 2 / 4 / 7 TAGs

4.2 Historical — feature/sfa-curve-buffer-spike (Draft v3 origin)

Bucket	Summary
arch:	Structural CompoundCurve — segment-aware copy / toLinear
arch:	Member-structured WKT round-trip for CompoundCurve
arch:	CurveShapeWriter walks CompoundCurve members, arc-renders
feat:	LineHandlingFunctions.mergeCurves (arc-aware sibling of mergeLines)
fix:	Anchor member control points in CompoundCurve.toLinear (no junction drift)
fix:	Block-comment paste regression in WKT panel
spec:	This epic + 49-method CurveAwarenessSpecTest red-test suite
(orig)	bufferCurveWithParams linearisation hook (Phase-5 spike entry)

#7 carried the SFA/SQL-MM types, WKT, and structural-type work forward from that spike. #8 stacked the PERF-GATE and the first lasers, then merged into #7. #10 (nested annulus) and #11 (odd-n tangent NSpan) merged after that. #12 / #13 stamp H-ANNULUS-TANGENT and related named misses. OV-P2 stacked drafts #16–#30 (nodes, faces, hole cells, OverlayNG-for-circles, leftover kits, Curve HotPixel) stay off #7.

5. Tracking model

We are not opening 49 separate issues. Fragmenting the project board, spamming notifications, and forcing every reviewer to reconstruct the dependency graph is the wrong shape for work this large.

Full-TAG red list: CurveAwarenessSpecTest

• Path: modules/curve/src/test/java/org/locationtech/jts/spec/curveawareness/CurveAwarenessSpecTest.java
• Run: mvn -pl modules/curve test -Dtest=CurveAwarenessSpecTest
• Still has all 49 fail() methods. That “delete the method when a TAG ships” meter froze when work moved to stacked PRs and closed-form lasers.
• The class is the full-TAG red list, excluded from default Surefire. It is not the live scoreboard. Do not delete a method because a closed-form subset landed (OV Phase 0, R-PR disc cells, disc area, TestBuilder Hausdorff, …). Delete only when the full TAG ships.
• Local silence while working: mvn -Dtest='!CurveAwarenessSpecTest' test.

Live progress meter

Remaining full TAGs (still red in the spec class) plus the green tests next to production code on #7. A maintainer reading this epic should look at OverlayNGCurve / CurveExact / WKB tests on #7, not at “49 methods remaining”.

GitHub layout

• This document is the suggested epic body — adapt as the maintainers see fit.
• Optional milestone-shaped issues per phase with checklists referencing TAGs — at most 8 of them, never 49.
• Day-to-day work via PRs that:
  • Reference this epic.
  • Use the TAG in commit subject + PR title.
  • Delete the corresponding red-test method only when the full TAG lands (its own commit, see conventions below). Partial lasers keep the spec method.

Commit / PR convention

bucket: TAG short description

Buckets: fix:, feat:, arch:, test:, spec:, refactor:. (User-facing docs go under spec:.)

Examples:

• feat: BUF-1 analytical single-arc CircularString buffer → CurvePolygon
• arch: F-CP CurvePolygon stores CompoundCurve shell + holes
• test: drop CurveAwarenessSpecTest#test_BUF_1_* — the dedicated commit that closes a full TAG by removing its red-test method.

6. Cross-module impact

Most TAGs ship purely inside jts-curve (extension module, opt-in). A handful require touching jts-core and therefore need a maintainer review up-front. Calling them out before they're proposed:

TAG group	jts-core change?	Notes
WKB 8–12	Yes (landed, now on #7)	WKBReader switch, WKBConstants 8–12, GeometryFactory create* stubs (default throw). CurveGeometryFactory / CurveWKBWriter / CurveWKBReader stay in jts-curve.
F-RD	Possibly	Only if ShapeWriter needs new extension hooks for CurvePolygon rings.
N-AA, N-AL, N-SS	Yes	SegmentString / Noder hierarchy lives in core. Largest remaining core surface in the epic.
OV	Indirect	OV-P1 (kits + named misses) shipped in jts-curve without a public noder. General overlay (OV-P2) still depends on N-SS; the pipeline itself stays in core.
R-PR, R-CONT	Indirect	RelateOp lives in core. Disc cells shipped via CurveExact in jts-curve. General “any curved/flat pair” still wants N-SS.
PLG	Yes	Polygonizer lives in core; needs to accept CompoundCurve edges.
PRC-SN	Yes	PrecisionModel.makePrecise integration.
DSF	Yes (or shadow)	Densifier lives in core; alternative is to wrap and shadow it from jts-curve.

Everything else is jts-curve-only or jts-app (TestBuilder).

7. Risks / open questions

• Backwards compatibility on structural composites. Algorithms that don't recognise a curve subtype today silently densify. After F-CP, a third-party algorithm that doesn't know about the new structural CurvePolygon ring will see a CompoundCurve shell where it expected a LinearRing, and may throw. We need a fallback contract: the structural ring must implement enough of LinearRing's contract to keep old code limping (read-only chord coords still available), or the structural CurvePolygon must fail fast with a clear message instead of silently going wrong.
• equalsExact semantic change (R-EQ). Today CIRCULARSTRING(p0,p1,p2).equalsExact(LINESTRING(p0,p1,p2)) returns true via shared coordinates. Making it false is per spec, but it's a behaviour change for any user comparing-by-WKT-text. Needs a release note. Still open.
• Non-similarity affine (AT-NS). Sheared arcs are ellipse arcs, which JTS doesn't model. The plan is to detect-and-densify, but: what does getGeometryType() return on the result? If LineString, we've changed the type silently. If still flagged as CircularString, the polyline lies about its identity. Decide before AT-NS lands.
• Performance of public arc-arc / arc-line intersection (N-AA, N-AL). The two-circle solve is fine for low cardinality, but MCIndexNoder-equivalent indexing of arc spans (bounding-box pruning of arcs) is non-trivial. Worth a benchmark before committing to a design. R1.6 uses line–circle clip internally; that is not the public utility.
• Z / M propagation across densified arcs. Out of scope for behaviour changes here, but every TAG that produces densified output (DSF, AT-NS, …) should choose a Z/M policy that doesn't lock us out of a proper interpolation later.
• ESRI Bezier3Curve. Not an ISO type: 13249-3 allocates it no code, and the first genuinely free slot is 26, since 25 belongs to BrepSolid (1025 is 25 + the Z offset). Two options, undecided. Either carry it as a first-class extension type, which means proposing a code allocation somewhere it can actually be registered; or keep it out of the persisted model entirely and use cubic Bézier only as an internal, performance-oriented approximation at segment seams, never written to WKB. The second costs nothing in interop and is the default until someone needs the first.

8. Definition of Done (epic-level)

The epic closes when all of:

1. CurveAwarenessSpecTest is empty — every TAG's red test deleted, replaced by green tests next to its production code.
2. Every ISO/IEC 13249-3 extended type listed in §3 round-trips through every public Geometry operation in the user guide without producing flat output where curve-preserving output is mathematically possible.
3. WKB type codes. All of §3's codes read through core WKBReader with a curve-capable factory, and CurveWKBWriter emits them. Codes 8–12 are done on include ora and sde modules #7; 15–24, 102 and 1025 remain. (Z / M interpolation stays out of scope, as in §3.)
4. A release note covers the equalsExact change (see §7) and any other user-visible behaviour shifts.

TB-FN (function-tree curve-awareness badges) is a stretch goal, not a DoD criterion. Annotating every entry in TestBuilder's function tree is a multi-week task with low payoff relative to the algorithm work, and shouldn't gate epic closure.

9. Phases — work breakdown

Phases group TAGs that share dependencies or naturally land together. Within a phase, TAGs are usually independently shippable. Cross-phase dependencies are noted explicitly per phase.

Closed-form subsets of Phase 6 (and pieces of Phases 2–4) already landed on #7 without Phase 5. That does not turn those TAGs green. Annotate partial and name the subset. OV-P1 is flipped (kits + named misses). General overlay / polygonizer / coverage / equalsExact still wait on Phase 5 (OV-P2).

Phase 1 — Foundations (jts-curve structural completeness)

Mirror the CompoundCurve work onto the remaining composite types.

• F-CP Structural CurvePolygon — CompoundCurve shell + holes; copyInternal, toLinear, WKT reader/writer preserve structure.
• F-MC Structural MultiCurve — preserves member subtypes (LineString / CircularString / CompoundCurve).
• F-MS Structural MultiSurface — preserves Polygon vs CurvePolygon member subtypes.
• F-RD CurveShapeWriter for CurvePolygon rings, MultiCurve and MultiSurface members.

Hard prereq for: all of Phase 2 (you can't return a CompoundCurve boundary of a CurvePolygon whose ring isn't a CompoundCurve to begin with).

Phase 2 — Properties (Metrics, Boundary, Validity)

• M-LEN-CS / M-LEN-CC — analytical arc length.
• M-AREA-CP — Green's-theorem area with circular-segment correction. Partial (circular discs): disc CurvePolygon area is 25π. Keep the spec method.
• M-DIM — empty-curve dimension/coordinate-dimension guards.
• B-CP / B-MS / B-CC — curved boundaries.
• V-CP — CurvePolygon validity (arc self-intersection, sector orientation, holes-in-shell).
• V-CS — CircularString / CompoundCurve simplicity.

Depends on: Phase 1 (F-CP is a hard prereq for B-CP, M-AREA-CP, V-CP).

Phase 3 — Measurement (Distance, Centroid, Interior point)

• D-PT / D-AA — analytical point-arc and arc-arc distance. Closed-form helpers exist in CurveExact; the public DistanceOp TAG is still red.
• D-OP — DistanceOp accepts curved inputs without forced densification. Still the public TAG; keep the spec method.
• D-HF — public DiscreteHausdorffDistance two-pair lock via 0ca71b (APEX; two discs). Exact path skips densify. Public DHD still chords in general. Fréchet still open. Keep fail(). Not “parameterise by arc length”.
• C-LIN / C-AREA / C-IP — centroids and interior point.

Depends on: Phase 1 (F-CP for CurvePolygon cases).

Phase 4 — Construction (Buffer, Hulls, Simplification, Affine, Linear-Ref, Densifier)

• BUF-1 / BUF-N / BUF-NEG — analytical buffer. Open-arc buffer still open.
• OFF / VBF — offset curve and variable buffer. OFF = concentric arc (refactor) still open.
• H-CV / H-CC — convex hull. H-CV / H-CC partial: disc, single-arc, and CompoundCurve hulls landed. Clothoid hull is a linear fallback. ConcaveHull stays out.
• S-DP / S-VW / S-TP — simplification preserves arc identity.
• AT-S / AT-NS — affine transforms (similarity preserves; non-similarity densifies — see §7 risk).
• LRF-LEN / LRF-LOC — linear referencing parameterised by arc length.
• DSF — densifier delegates to toLinear.

Depends on: Phase 1 (output may be CurvePolygon).

Phase 5 — Noding foundation

• N-AA — public arc-arc intersection utility. Still red.
• N-AL — public arc-line intersection utility. Still red. Line–circle clip is used inside R1.6; that is not this TAG.
• N-SS — CurveSegmentString inside jts-curve only; no public SegmentString or noder. #27 stays a dead-end. Still off include ora and sde modules #7.

Depends on: Phase 1. Touches jts-core — see §6. Phase 6 general overlay still depends on N-SS.

Phase 6 — Overlay, Predicates, Polygonizer, Coverage

• OV — arc-preserving overlay output (union / intersection / difference / symDifference). OV-P1 flipped: OverlayNGCurve kits (R0 / R1 / R1.5 discs + nested annulus / R1.6 disc-vs-polygon / R1.7 CompoundCurve shells including even-n and tangent-odd NSpan / R-LL / R-AA). On include ora and sde modules #7 the leftover named misses are still H-SHELL-N-MIXED, H-SHELL-HOLE-CROSS, H-SHELL-HOLE-X, H-ANNULUS-TANGENT; stacked drafts sew the hole cells and take a first OverlayNG cell for H-SHELL-N-MIXED. H-ANNULUS-TANGENT stays a named miss. Not a general circular noder. Do not mark the full OV TAG green. OV-P2 is Bar 2.
• R-PR / R-CONT / R-EQ — arc-aware relate, predicates, exact equality. R-PR / R-CONT partial: certified disc PIP; DE-9IM for disc vs Point / LineString / hole-free Polygon / second disc; MultiSurface unwrap; SFS table; two areas never crosses. Half-disc / CompoundCurve still null → linearise. R-EQ (arc-vs-chord equalsExact) still open.
• PLG — Polygonizer accepts CompoundCurve edges and emits CurvePolygon faces.
• COV — CoverageUnion preserves shared arc edges.

Depends on: Phase 5 for general OV / PLG / COV / R-EQ. Phase 6 subsets already landed without N-SS — see §4.1 and §10.

Phase 7 — Independent tracks

Three single-theme tracks that depend only on Phase 1 and have no inter-dependencies; can land in parallel with Phases 2–6 once Phase 1 ships.

• Snapping
  • PRC-SN — snap-to-grid preserves arc when the snapped (R, centre, sweep) still lies on grid; otherwise densify-and-snap chords.
• Triangulation / Voronoi
  • TRI-DT / TRI-VR — DelaunayTriangulationBuilder / VoronoiDiagramBuilder accept curved boundary input (densify internally via toLinear(tolerance)).
• TestBuilder
  • TB-T — CompoundCurveTool, CurvePolygonTool drawing UX.
  • TB-FN — function-tree curve-awareness badges (●/◯/✕). Stretch goal — see §8.
  • Visual QA still open: TestBuilder inspector ClassCastException.

Most of Phase 2 / 4 / 7 TAGs are still the full red list. Also still open (not a phase of their own): RocqRefRunner SQL/MM suite for public Curve predicates. LEC (typed obstacle distance for point / segment / polygon / arc / disc) landed on #7 — keep the spec method if the public TAG is wider than that subset.

10. Suggested order

Phase 1 (Foundations)
   │
   ├──> Phase 2 (Properties)            M-AREA-CP partial: circular discs
   ├──> Phase 3 (Measurement)           D-HF two-pair (Fréchet still open); LEC typed obstacles
   ├──> Phase 4 (Construction)          H-CV / H-CC partial: disc / single-arc / CompoundCurve hulls
   ├──> Phase 5 (Noding)  ──>  Phase 6 *general* OV-P2 / PLG / COV / R-EQ
   │
   └──> Phase 6 *OV-P1* (already on #7, did not wait for N-SS)
            OverlayNGCurve kits (R0 / R1 / R1.5 / R1.6 / R1.7 / R-LL / R-AA)
            named R2 misses; R-PR / R-CONT closed-form disc cells
   └──> Phase 7 (Independent tracks: snap / triangulation / TestBuilder)

After Phase 1 finishes, Phases 2 / 3 / 4 / 5 / 7 can run in parallel. OV-P2 (circular noder + arrangement) still waits for Phase 5. OV-P1 (kits + named misses) already shipped on #7 without a public noder. The phase graph must not say “overlay requires a noder” as if those kits were blocked.

11. Conventions

• TAGs are short, unique, and stable. Renaming a TAG renames its test method too.

• One TAG per PR (or a tightly-coupled cluster). The PR deletes the corresponding spec method only when the full TAG lands. Partial lasers keep the method.

• CI stays green by default. The spec class is excluded from the default Surefire run via:

  <plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
      <excludes>
        <exclude>**/spec/curveawareness/*.java</exclude>
      </excludes>
    </configuration>
  </plugin>

  Contributors run it explicitly with mvn -pl modules/curve test -Dtest=CurveAwarenessSpecTest (which overrides the exclude). The remaining-method count is the full-TAG red list, not the live progress meter (see §5). It does not break CI on every push.

12. References

• ISO/IEC 13249-3 (SQL/MM Part 3: Spatial) — §5.1.67 <well-known text representation>, §5.1.68 <well-known binary representation> and its Table 15 of <uint32> type codes.
• Wiener Bogen — Wikipedia (de) and EP1523597B1, for the encumbered-form example in §3.1.
• jts-curve source: modules/curve/.
• #7 feature/sfa-curve-rgr @ b2861a08 — SFA/SQL-MM types, WKT, WKB 8–12, OverlayNGCurve OV-P1, logo-as-curves.
• #8 (merged into include ora and sde modules #7) — PERF-GATE + first lasers. #10 annulus, #11 odd-n. Bar 2 / #38 / #27 stay off include ora and sde modules #7.
• OverlayNGCurve (package-private overlay helpers in org.locationtech.jts.operation.overlayng.curve).
• CurveExact (package-private in org.locationtech.jts.geom.curve).
• GEOS src/io/WKBReader.cpp / WKBWriter.cpp / include/geos/io/WKBConstants.h — type codes 8–12 and child-WKB layout.
• Spike branch (origin): feature/sfa-curve-buffer-spike on grootstebozewolf/jts.
• CurveAwarenessSpecTest — full-TAG red list (49 fail() methods still present; excluded from default Surefire). Live meter: include ora and sde modules #7 green tests + remaining full TAGs.

[grootstebozewolf]

Focused spike landed on the fork for one TAG: F-CP — Structural CurvePolygon. Branch: feature/sfa-curve-F-CP-spike (single commit, spike-only, no production-code change yet).

Why F-CP first

Walking the 49 TAGs against the §6 cross-module table, §7 risk register, and the §10 phase graph, F-CP stands out:

• Critical path. Hard Phase-1 prereq for every Phase-2 TAG that needs to talk about a curved boundary, area, or validity (B-CP, M-AREA-CP, V-CP). Phase 2 can't ship until F-CP does.
• §7 risk Deleted unsupported modules: jts-jump, libjts, jts-sde-adapter. #1 lives here. Polygon.getExteriorRing() is typed LinearRing; a structural CurvePolygon's actual shell is a CompoundCurve. Those two facts can't both be true at runtime — the dovetail choice has to be made before the implementation PR, not inside its review.
• Already interacts with shipping code. PR #1194 ships a Phase-1 stand-in that silently linearises CurvePolygon rings on read. Any future structural form has to coexist with or replace that path.
• Precondition met. The feature/sfa-curve-compoundcurve-members branch on the fork (commit 29723a30) restructures CompoundCurve to store LineString[] members with getCurveN(int) / getNumCurves(). F-CP picks up from there — the spike's helpers already bridge to that API by reflection so the red tests compile against the current extension-points head.

What's on the spike

• CurvePolygonStructuralSpec.java — 8 red tests covering 7 F-CP sub-TAGs (FCP-S / FCP-MEM / FCP-H / FCP-CP / FCP-TL / FCP-WKT / FCP-DOVE), each fail() naming its sub-TAG so the message stream stays a live progress meter for the F-CP sub-surface, mirroring the role of CurveAwarenessSpecTest at the epic level.
• SPEC_F_CP.md — captures the FCP-DOVE branching table with trade-offs, where we lean, and what's deferred.
• modules/curved/pom.xml — adds the Surefire exclude **/spec/curveawareness/*.java per §11 so the spike's red tests don't redden default CI. On-demand: mvn -pl modules/curved test -Dtest=CurvePolygonStructuralSpec.

Posture verified: default reactor build BUILD SUCCESS with checkstyle (55 jts-curved tests green); explicit spec run yields 8 failed / 8 run with TAG-tagged messages.

The dovetail decision (FCP-DOVE)

Three live options for what Polygon.getExteriorRing() returns on a structural CurvePolygon:

Option	getExteriorRing()	New accessor	Trade-off summary
A — legacy fallback	LinearRing of densified chord coords at a default tolerance	getExteriorCurve() returns the structural Curve	Two-tier API; old callers keep working but see a polyline approximation. Lowest friction for jts-core.
B — widen return type	LineString (CompoundCurve extends LineString)	none — existing method suffices	Single source of truth, no API doubling. Breaks every caller that does (LinearRing) p.getExteriorRing() — needs a core-wide audit.
C — fail-fast	throws UnsupportedOperationException	getExteriorCurve() returns the structural Curve	Loudest diagnostic; forces every caller to migrate. Probably only acceptable behind a feature flag.

We lean A today (lowest blast radius on jts-core, two-tier API as the deliberate cost). B becomes attractive again if the number of (LinearRing) casts on getExteriorRing() results inside jts-core turns out to be small — that count is the deciding number. Full trade-offs and what's deferred (default tolerance, getCoordinates() policy, hole symmetry) are in SPEC_F_CP.md.

Smallest concrete next step

A one-line A / B / C reply from a maintainer on this issue. After that:

1. An arch: commit on the spike branch deletes the unselected rows from SPEC_F_CP.md to record the decision.
2. A separate implementation PR starts from there: updates to CurvePolygon, CurvedGeometryFactory, CurvedWKTReader.readCurvePolygonText, CurvedWKTWriter, and deletes the now-green methods in CurvePolygonStructuralSpec per the §5 convention.

The door is deliberately left open — if a Phase-2 TAG surfaces a constraint we missed before the implementation PR lands, revisiting the option is fair game. Post-merge it becomes a breaking change.

---

Assisted-by: Claude (Opus-4.7)

[grootstebozewolf]

F-CP / FCP-DOVE — three option spikes ran; B and C ruled out

Per the request to continue the spike until each option is ruled out or surfaces benchmarks, ran a branch per option. All three spikes are now on the fork; B and C produce strong rule-out evidence, A flips half the F-CP red tests green and exposes only secondary design questions that are implementation-PR scope.

Branches

Option	Branch	Build	F-CP reds
A — legacy fallback (getExteriorCurve() + legacy getExteriorRing())	feature/sfa-curve-F-CP-spike-optionA	BUILD SUCCESS, 55/55 Phase-1 tests green	4 of 8 flip green
B — widen Polygon.getExteriorRing() return type to LineString	feature/sfa-curve-F-CP-spike-optionB	intentionally non-compiling	n/a
C — fail-fast on getExteriorRing()	feature/sfa-curve-F-CP-spike-optionC	compiles, but 2 existing curved tests regress	not measured (probe instead)

Cast survey first

Across modules/core/src/main/java:

Pattern	Count
getExteriorRing() call sites	57
getInteriorRingN() call sites	47
explicit (LinearRing) casts on either result	10

The 10-cast number is what the spec doc bet B on. The real measurement (below) is much larger.

Option A — feasible, minimal, no regressions

Diff: +60 / −8 across CurvePolygon, CurvedWKTReader, and the spike helpers. Adds a new field LineString structuralShell, a new constructor that derives the legacy LinearRing shell via Linearizable.toLinear(0.0), a new getExteriorCurve() accessor, and updates copyInternal() to preserve the structural shell.

Test posture on the A branch:

• 55/55 jts-curved Phase-1 tests stay green — no regressions
• 4 of 8 FCP red tests flip green: FCP-S (compound shell), FCP-S (single-arc), FCP-CP (copy preservation), FCP-DOVE (the design-decision marker)
• 4 reds remain — but each tracks an independent sub-TAG that A/B/C all share equally:
  • FCP-MEM waits on feature/sfa-curve-compoundcurve-members
  • FCP-H is the parallel getInteriorCurveN(int) accessor (cosmetic)
  • FCP-WKT is a writer-side TAG (separate sub-issue)
  • FCP-TL waits on feature/sfa-curve-toLinear-densification

One open question A defers to the implementation PR: the default tolerance source for the linearised getExteriorRing() view. Today's toLinear(0.0) ignores the tolerance argument; a real implementation parameterises on PrecisionModel scale or a CurvedGeometryFactory field. Not an A-vs-B-vs-C decision.

Option B — RULE-OUT for Phase 1

Two-method widening of Polygon from LinearRing to LineString (the entire mechanical surface of B). Then mvn -pl modules/core compile:

Metric	Count
Compile errors in jts-core/main	108
Distinct files affected	25
Highest-impact file	operation/valid/IsValidOp.java (12 errors)
Files with 4+ errors	19 of 25

The original 10-cast number undercounted by 10×. The compiler also flags every implicit assignment (LinearRing r = polygon.getExteriorRing() with no cast) and every pass-through into new Polygon(LinearRing, ...). Full breakdown in NOTE_OPTION_B.md and the raw mvn error log preserved at SPIKE_OPTION_B_compile_errors.txt.

Beyond the 108 sites, B fails the "single source of truth" sales pitch: the Polygon constructor still takes LinearRing shell, LinearRing[] holes, so most of the 108 fix sites end up adding explicit (LinearRing) casts to satisfy the constructor — recreating the two-tier API Option A would have made explicit. And the API change is binary-incompatible for every downstream consumer (PostGIS-Java, GeoTools, etc.).

Verdict for Phase 1: no. B remains viable as a post-A deprecation cycle — widen the API, keep the LinearRing-returning method as a deprecated shim, do the 108-site sweep over multiple PRs.

Option C — RULE-OUT, including as a feature flag

Override getExteriorRing() and getInteriorRingN(int) on CurvePolygon to throw UnsupportedOperationException; route internal copyInternal() / toLinear() via super.* calls.

Blast-radius probe (OptionCBlastRadiusProbe.java) pipes a CURVEPOLYGON(CIRCULARSTRING(0 0, 10 0, 5 5, 0 5, 0 0)) through 32 representative jts-core operations:

total: 32   ok: 16   UOE: 16   other-error: 0

50 % blast radius. What survives: methods that read Polygon's internal shell field directly (getCoordinates, getArea, getLength, getBoundary, copy, normalize, isSimple, plus all geometry-metadata). What breaks: every relational predicate (intersects / contains / intersection / union / difference / distance), buffer, getCentroid, getInteriorPoint, convexHull, reverse, isValid, toText, and the curve-aware CurvedWKTWriter.write() itself.

Empirical confirmation in the unchanged Phase-1 suite: two existing curved-module tests break under Option C without any test-code edit — WKTCurvePolygonTest.testWKTRoundTripXY and WKTMultiSurfaceTest.testWKTRoundTripXY, both via CurvedWKTWriter → appendPolygonText → getExteriorRing() → UOE.

A feature-flagged C reduces to "A with an optional explosion mode" because the flag-off behaviour has to be either A or B. Verdict: rule out as the default contract. C survives as a useful idea in a smaller scope: a CurvedGeometryFactory diagnostic-mode wrapper that strict pipelines opt into to confirm no non-curve-aware code touches their CurvePolygons. That's a separate, smaller feature.

Recommendation

Land F-CP under Option A. A is the only option that ships without a sweeping core PR or a 50% method-availability hole, and the spike shows it's a ~60-LOC additive change with no regressions.

The implementation PR's remaining open questions (default linearisation tolerance, getCoordinates() policy, hole-symmetry timing) are all scoped to A's implementation, not to the A-vs-B-vs-C choice.

If maintainers want to keep B alive as a future cleanup, the right shape is "A now, B-style widening in a follow-up release with a deprecation cycle" — captured at the bottom of NOTE_OPTION_B.md.

The door's still open if a Phase-2 TAG surfaces a constraint that changes the trade-off before the F-CP implementation PR lands.

---

Assisted-by: Claude (Opus-4.7)

[grootstebozewolf]

Continuing — F-MC + F-MS Phase-1 finish, AT-NS §7-risk-#3 spike

Two more workflow loops on the fork:

TAG group	Branch	Status
F-MC + F-MS (composite-member preservation)	feature/sfa-curve-F-MC-F-MS-spike	Phase-1 reader half already free, writer half closed
AT-NS (affine on curved geometry, §7 risk #3)	feature/sfa-curve-AT-NS-spike	three-option spec + probe; lean Option A

F-MC + F-MS — half-already-free, half-closed

Wrote a 6-test red spec and ran it against the PR-1194 base before touching code. Four of six green on the unchanged base:

• FMC-READ, FMC-COPY — MultiCurve preserves CircularString / CompoundCurve member subtypes via CurvedWKTReader.readCurveMember's dispatch through readGeometryTaggedText; MultiLineString.copy() propagates each member's runtime class through copyInternal() without F-CP-style storage redesign.
• FMS-READ, FMS-COPY — same shape for MultiSurface holding plain Polygon + CurvePolygon members.

The two reds were both writer-side: MULTICURVE and MULTISURFACE round-tripped through CurvedWKTWriter.write() came back as flat polylines/polygons because WKTWriter.appendMultiLineStringText / appendMultiPolygonText emit per-member body-only bodies, dropping the type tag.

Fix: ~75 LOC additive on CurvedWKTWriter, overriding the appendOtherGeometryTaggedText hook from PR #1194 to intercept MultiCurve and MultiSurface. Per-member emission emits body-only (x y, …) for plain LineString / Polygon members and tagged CIRCULARSTRING (…) / COMPOUNDCURVE (…) / CURVEPOLYGON (…) for curve members. No jts-core change — the extension hook already in place handles the seam.

Posture: default mvn -pl modules/curved test is 55/55 green, on-demand spec is 6/6 green, full reactor with checkstyle is BUILD SUCCESS.

Phase-1 status after this branch:

TAG	State
F-CP	pending — Option A recommended in earlier comment
F-MC	reader done on base; writer closed by this spike
F-MS	reader done on base; writer closed by this spike
F-RD	TestBuilder rendering — separate Phase 4-B / lab work

Once F-CP lands under Option A, Phase 1 is structurally complete and Phases 2/3/4/5/7 unlock per the §10 graph.

AT-NS — §7 risk #3 with branching table + probe

Followed the same shape as FCP-DOVE: a SPEC_AT_NS.md with a three-option branching table, an 8-test red spec pinned to the lean option, and a current-behaviour probe so the measurement is reproducible.

Branching table

Option	Non-similarity behaviour	getGeometryType()	Trade-off
A — silent densify	densify via toLinear(tolerance), then transform the polyline	result is LineString	Geometrically faithful; type changes silently. Matches §7's "detect-and-densify".
B — preserve type, accept drift (today)	transform the 3 control points; the new arc is the circle through transformed points	CircularString (lies)	Type stable; geometrically wrong for shears / non-uniform scales.
C — fail-fast	detect non-similarity, throw UnsupportedOperationException	n/a	Loudest diagnostic. Probably only acceptable behind a strict-mode flag.

Probe output, today

transform                  similarity?  out-type        out-pts  control-pts-on-circle?
identity                   true         CircularString  3        true
translate(10, 20)          true         CircularString  3        true
scale(2, 2) uniform        true         CircularString  3        true
rotate(pi/4)               true         CircularString  3        true
reflect x-axis             true         CircularString  3        true
scale(2, 1) non-uniform    false        CircularString  3        true   <-- LIES
scale(3, 1) non-uniform    false        CircularString  3        true   <-- LIES
shear-x 0.5                false        CircularString  3        true   <-- LIES

The probe carries a static isSimilarity(AffineTransformation) helper using the standard linear-algebra test (a² + c² == b² + d² and ab + cd == 0). It correctly flags every non-similarity, but apply(...) still returns a CircularString — Option B in action. The "on-circle" column is the geometric sanity check: 3 distinct non-collinear points always lie on some circle, so the result is a valid CircularString syntactically even when it has nothing to do with the elliptical image of the original arc.

Where we lean

Option A. Three reasons in SPEC_AT_NS.md:

1. It is the only option where the result is a faithful representation of the affine image of the original arc. B's result is a different geometric curve entirely; C avoids the question.
2. The type change is observable and recoverable: a curve-aware caller can branch on g.getGeometryType() after the call.
3. A drops in cleanly with the existing Linearizable contract; the non-similarity branch becomes one call to toLinear(tolerance) followed by transforming the linearised result. The toLinear half is already done on feature/sfa-curve-toLinear-densification.

B remains reachable via a three-line escape hatch for callers who want it (transform the CoordinateSequence directly and rebuild the CircularString). C survives as a CurvedGeometryFactory strict-mode flag — same diagnostic-mode role as FCP-DOVE Option C.

Smallest concrete next step

A one-line A / B / C ack on this issue, then an arch: commit on the spike branch pinning the choice in SPEC_AT_NS.md, then the implementation PR overrides apply(...) on each curve type with the similarity-detection + densify branch. The 8-test spec class shrinks to zero as the implementation lands per the §5 convention.

Phase-1 critical path now

F-CP   (Option A picked, awaiting ack -> implementation PR)
F-MC   (closed by F-MC-F-MS-spike, awaiting merge upstream)
F-MS   (closed by F-MC-F-MS-spike, awaiting merge upstream)
F-RD   (TestBuilder UI, separate track)

AT-NS  (Option A leaning, awaiting ack)

Door is open on every option if a downstream TAG surfaces a constraint that changes the trade-off before the implementation PR lands.

---

Assisted-by: Claude (Opus-4.7)

[grootstebozewolf]

Continuing — R-EQ §7-risk-#2 spike + PRC-SN Phase-7 spike

Two more rounds, both following the FCP-DOVE / AT-NS shape (spec doc + red-test class + probe + lean):

TAG	Branch	Position
R-EQ (§7 risk #2 — equalsExact semantics)	feature/sfa-curve-R-EQ-spike	Option A implemented and measured; zero regressions
PRC-SN (Phase 7 — snap-to-grid)	feature/sfa-curve-PRC-SN-spike	spec + probe; reveals today's reducer is more aggressive than Option C

R-EQ — measured at minimal cost

Root cause: LineString.isEquivalentClass is lenient (other instanceof LineString) so a CircularString calling equalsExact with a coordinate-identical LineString passes the equivalence gate and returns true. Polygon does not override isEquivalentClass, so CurvePolygon.equalsExact(Polygon) is already correctly false today — R-EQ is narrowly scoped to the two LineString-extending curve types.

Branching table

Option	Approach	Symmetry	Trade-off
A — override isEquivalentClass strict on curve side	curve overrides only	asymmetric (cs.eE(ls)==false, ls.eE(cs)==true)	Minimal, fixes the §7 violation, no jts-core change
B — tighten LineString.isEquivalentClass everywhere	breaks LinearRing↔LineString	symmetric	Much bigger jts-core change; future deprecation cycle
C — new parallel method	preserves all current behaviour	n/a	Adds API; doesn't fix equalsExact for existing callers

Lean: Option A. Implemented on the spike branch: two-method change (isEquivalentClass on CircularString and CompoundCurve).

Probe before/after the override

                              today (Option B baseline)   spike branch (Option A)
cs.equalsExact(ls)            true   <-- WRONG            false  <-- fixed
cc.equalsExact(ls)            true   <-- WRONG            false  <-- fixed
cc.equalsExact(cs)            true   <-- WRONG            false  <-- fixed
cs.equalsExact(cc)            true   <-- WRONG            false  <-- fixed
ls.equalsExact(cs)            true   <-- documented asym  true   <-- unchanged
cs.equalsExact(cs)            true                        true
lr.equalsExact(ls')           true   <-- intentional      true   <-- preserved
ls'.equalsExact(lr)           true   <-- intentional      true   <-- preserved
poly.equalsExact(ls)          false                       false

Posture: default mvn -pl modules/curved test is 55/55 green (zero regressions). On-demand spec is 6/6 green. The asymmetric ls.equalsExact(cs) == true is preserved by design — tightening LineString.isEquivalentClass would break the intentional LinearRing ↔ LineString equivalence, which is a much larger change. Documented in SPEC_R_EQ.md "asymmetry trap" + an explicit test (test_R_EQ_asymmetryIsDocumentedAndAccepted) that documents the contract.

Implementation PR is trivial: cherry-pick the two overrides, add a release-note bullet, add Javadoc on each curve type calling out the asymmetric contract.

PRC-SN — Phase 7 independent track with a surprising discovery

Spike followed the SPEC + probe + red-tests shape. The branching table is in SPEC_PRC_SN.md:

Option	Approach	Type stability
A — snap control points	preserved (type), arc drifts	The §7 "preserve on grid" branch
B — snap (R, centre, sweep)	preserved (type and arc)	Hard; not every snapped arc has control points on grid
C — densify then snap	LineString	The §7 "otherwise densify" branch
D — A when grid-friendly, else C	adaptive	The §7 phrasing made code

Lean: Option D, with a defined "grid-friendly" criterion: the snapped circle through the three snapped control points must have both centre and radius on the grid.

The discovery — today is worse than Option A or C

GeometryPrecisionReducer.reduce unconditionally strips CircularString to LineString via GeometryEditor.GeometryEditorOperation — even when there's nothing to snap:

input description                       out-type        out-pts  arc drift
integer-aligned half-circle             LineString      3        none
sub-cell drift snapping to integers     LineString      3        centre (4.89, 0.61) → (5.00, 0.00); R 4.81 → 5.00
sub-grid arc (off-grid centre)          LineString      3        centre (0.85, -0.31) → (0.50, 0.50); R 0.82 → 0.71
near-degenerate small arc               LineString      0        all coords collapse to origin
quarter-circle on grid                  LineString      3        none

Even the grid-aligned half-circle (CIRCULARSTRING (0 0, 5 5, 10 0)) loses its arc identity because the reducer's GeometryEditor rebuilds via the GeometryFactory.createLineString, which has no CircularString awareness.

So the choice isn't "A vs D" — the current behaviour is more aggressive than C (always degrade type, even when there's nothing to snap). PRC-SN is the right place to introduce any curve-type preservation through the precision reducer. Once the infrastructure exists, layering the grid-friendly check on top is straightforward.

Spec posture: 6 tests, 4 red / 2 green. The two greens pass for the wrong reason (today degrades unconditionally, which happens to match Option D's fallback assertion). The reds capture the gap. Probe runs on demand.

Implementation PR sketch: a new org.locationtech.jts.precision.curved.CurvedPrecisionReducer with isGridFriendly(CircularString, PrecisionModel) and a reduce(Geometry, PrecisionModel) entry point that dispatches curve subclasses through the Option-D branch and delegates to the standard reducer for everything else.

§7 risk register status after this round

Risk	TAG	Status
#1 — F-CP backward compat	FCP-DOVE	Option A recommended (earlier)
#2 — equalsExact semantics	R-EQ	Option A implemented + measured (this round)
#3 — non-similarity affine	AT-NS	Option A leaning (previous round)
#4 — arc-arc/arc-line indexing performance	N-AA / N-AL	not yet — needs benchmark spike (post Phase-5 design)
#5 — Z/M propagation across densified arcs	spans BUF / DSF / AT-NS / PRC-SN	tracked as a deferred policy item per spec docs

Plus PRC-SN (Phase 7) now has a spike and a discovery that informs Phases 2/3/4 too: any operation that goes through GeometryEditor will degrade curve types the same way the reducer does today. Worth flagging when those TAGs come up.

Door's still open on every option.

---

Assisted-by: Claude (Opus-4.7)