From jeroen.bloemscheer at merkator.com Sat Oct 24 05:13:02 2026 From: jeroen.bloemscheer at merkator.com (Jeroen Bloemscheer) Date: Sat, 24 Oct 2026 12:13:02 +0000 Subject: Review request: ST_Clothoid WKT/WKB support (libgeos/geos#1566) Message-ID: Hi all, I've opened a pull request adding a clothoid (Euler spiral) curve type to GEOS and would appreciate reviews: GEOS PR #1566 What it adds * A Clothoid geometry following ISO/IEC 13249-3:2016 ST_Clothoid, represented by an affine placement, scale factor, and start/end distances from the inflection point. * WKT read/write using the SQL/MM CLOTHOID syntax, including Z, M, ZM, and EMPTY. * WKB read/write as type 22, with 1022/2022/3022 for Z/M/ZM. * Length, envelope, and linearisation, including clothoid sections within a CompoundCurve. * GEOSGeom_createEmptyClothoid in the C API. Distance, intersection, and point-location operations currently throw on clothoids rather than silently falling back to a chord, so unsupported operations fail explicitly instead of returning an incorrect result. Numerics Points and headings are computed using Fresnel integrals. Beyond |t/A| = 9, the implementation switches to asymptotic auxiliary functions. Headings are reduced using a 159-bit representation of 2?, keeping accuracy at around 1e-16 of the curve extent even far from the inflection point. Tests compare against a high-precision reference and cover numerical edge cases and error paths. Where I'd especially appreciate feedback 1. The new GEOS_CLOTHOID type ID (13), particularly its ABI implications and the effect on code switching on GeometryTypeId. 2. The new virtual SimpleCurve::addLinearizedPoints, which allows CompoundCurve to linearise its sections without explicit type checks. 3. Whether throwing for unsupported operations is the right default, or whether some operations should linearise first. 4. The C API addition and WKB encoding. ISO WKB cannot mark an empty clothoid nested inside a collection, so the reader has a specific rule for that case. The PR is deliberately limited to I/O and basic curve support. ST_SpiralCurve, predicates, overlay, buffer, and GML are left for follow-up work. Thanks for taking a look. Jeroen Bloemscheer ________________________________ Jeroen Bloemscheer Geo-IT Consultant Zaltbommel [Merkator] m: +31 (0)6 478 728 18 e: jeroen.bloemscheer at merkator.com Merkator BV Hogeweg 137a 5301 LL Zaltbommel(NL) www.merkator.com [LinkedIn] ________________________________ This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen.bloemscheer at merkator.com Mon Oct 26 01:58:15 2026 From: jeroen.bloemscheer at merkator.com (Jeroen Bloemscheer) Date: Mon, 26 Oct 2026 08:58:15 +0000 Subject: Elliptical Curve, NURBS, Clothoid, Spiral Curve Message-ID: Hi all, I've added initial SQL/MM support for WKB types 20?23 (Elliptical Curve, NURBS, Clothoid, and Spiral Curve) and would appreciate a review of the implementation. At this stage, Distance, Intersection, and point-location operations are not yet supported. Before proceeding further, I believe an architectural decision is needed regarding the naming and hierarchy of segment types beyond the existing ArcSegment and LineSegment classes. Possible approaches include introducing specific types such as CurveSegment, NURBSSegment, etc., or defining a more generalized abstraction that can accommodate future curve segment implementations. While working on this, I also ran into and fixed three bugs that are now available as: * fix/arc-segment-distance * fix/arc-arc-distance * fix/envelope-touching-distance The bug fixes largely speak for themselves, but they did highlight some of the edge cases and assumptions that will likely become more important as support for additional curve types is expanded. For Circle support, I currently see two possible directions. One is to build on the newly implemented NURBS infrastructure, leveraging its flexibility and existing framework. The other is to extend CircularString directly. Both approaches have advantages and disadvantages in terms of implementation complexity, consistency, performance, and long-term maintainability. Feedback on the overall design, naming strategy, and preferred approach for Circle support would be greatly appreciated. Thanks, Jeroen Bloemscheer ________________________________ Jeroen Bloemscheer Geo-IT Consultant Zaltbommel [Merkator] m: +31 (0)6 478 728 18 e: jeroen.bloemscheer at merkator.com Merkator BV Hogeweg 137a 5301 LL Zaltbommel(NL) www.merkator.com [LinkedIn] ________________________________ This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbaston at gmail.com Mon Oct 26 16:14:18 2026 From: dbaston at gmail.com (Daniel Baston) Date: Mon, 26 Oct 2026 19:14:18 -0400 Subject: Elliptical Curve, NURBS, Clothoid, Spiral Curve In-Reply-To: References: Message-ID: Jeroen, What is the impetus behind this work? It's not at all clear to me that GEOS has the architecture or maintenance capacity to add these types. Dan On Mon, Oct 26, 2026 at 5:35?AM Jeroen Bloemscheer < jeroen.bloemscheer at merkator.com> wrote: > Hi all, > I've added initial SQL/MM support for WKB types 20?23 (Elliptical Curve, > NURBS, Clothoid, and Spiral Curve) and would appreciate a review of the > implementation. > At this stage, Distance, Intersection, and point-location operations are > not yet supported. Before proceeding further, I believe an architectural > decision is needed regarding the naming and hierarchy of segment types > beyond the existing ArcSegment and LineSegment classes. Possible approaches > include introducing specific types such as CurveSegment, NURBSSegment, > etc., or defining a more generalized abstraction that can accommodate > future curve segment implementations. > While working on this, I also ran into and fixed three bugs that are now > available as: > > - fix/arc-segment-distance > - fix/arc-arc-distance > - fix/envelope-touching-distance > > The bug fixes largely speak for themselves, but they did highlight some of > the edge cases and assumptions that will likely become more important as > support for additional curve types is expanded. > For Circle support, I currently see two possible directions. One is to > build on the newly implemented NURBS infrastructure, leveraging its > flexibility and existing framework. The other is to extend CircularString > directly. Both approaches have advantages and disadvantages in terms of > implementation complexity, consistency, performance, and long-term > maintainability. > Feedback on the overall design, naming strategy, and preferred approach > for Circle support would be greatly appreciated. > Thanks, > Jeroen Bloemscheer > ------------------------------ > *Jeroen Bloemscheer* > Geo-IT Consultant > Zaltbommel > > *[image: Merkator] * > > m: +31 (0)6 478 728 18 > e: jeroen.bloemscheer at merkator.com > > > Merkator BV > Hogeweg 137a > 5301 LL Zaltbommel(NL) > www.merkator.com [image: LinkedIn] > > ------------------------------ > > This email (including any attachments to it) is confidential, legally > privileged, subject to copyright and is sent for the personal attention of > the intended recipient only. If you have received this email in error, > please advise us immediately and delete it. You are notified that > disclosing, copying, distributing or taking any action in reliance on the > contents of this information is strictly prohibited. Although we have taken > reasonable precautions to ensure no viruses are present in this email, we > cannot accept responsibility for any loss or damage arising from the > viruses in this email or attachments. We exclude any liability for the > content of this email, or for the consequences of any actions taken on the > basis of the information provided in this email or its attachments, unless > that information is subsequently confirmed in writing. > -------------- next part -------------- An HTML attachment was scrubbed... URL: