[
Date Prev][Date Next][
Thread Prev][Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jts-dev] Proposal: geodesic (ellipsoidal) segment intersection - is this in scope for JTS?
|
On Sat, 29 Aug 2026, Dietmar Burkard wrote:
> Following the guidance in CONTRIBUTING.md to announce work before
> opening a PR, I would like to ask whether geodesic segment
> intersection is something JTS wants at all, and if so, where it
> should live.
Your four questions are the right ones, but I think there is a prior
question.
JTS is a planar engine. Noding, envelopes, monotone chains, indexes
and predicates all assume the affine plane. A geodesic on WGS84 is
not a richer LineString on that plane. It is a shortest path on a
different surface.
> 1. Is ellipsoidal/geodesic computation in scope for JTS at all?
> If the project's position is that JTS stays strictly planar and
> this belongs downstream in GeoTools or elsewhere, that is a
> completely reasonable answer and I would rather hear it now.
Possibly, but as a second geometric model, not as an extension of the
planar one. Staying strictly planar is a coherent answer. Ian already
noted that GeoTools would take it if JTS does not.
> 2. If it is in scope: where? jts-core in a new package such as
> org.locationtech.jts.algorithm.geodesic, or a separate module so
> that jts-core stays untouched?
A jts-geography module that owns inverse, direct and segment-segment
intersection on an ellipsoid. Not jts-core, not OverlayNG, not
Envelope, not MonotoneChain.
That is the same split PostGIS already uses: geometry stays planar
(GEOS/JTS); geodesic work lives on geography. GEOS itself has
CircularString I/O. It does not have GeodesicString, Karney, or an
ellipsoidal noder. There is nothing there to port.
> 3. jts-core has no dependencies today, which is why I wrote the
> geodesic code from scratch rather than depending on
> GeographicLib-Java (MIT). Is a self-contained implementation the
> right call, or would the project prefer the dependency route
> with an Eclipse CQ? The former is more code to maintain; the
> latter is less code but breaks the zero-dependency property.
The zero-dependency rule is a jts-core property. You wrote the
geodesic code from scratch so that rule would not be broken. If the
code lives in jts-geography instead, that rule does not apply. Then
GeographicLib-Java (MIT) plus an Eclipse CQ is the smaller
maintenance surface, and jts-core stays at zero dependencies. A
self-contained port is only the right call if the project insists
this land in jts-core.
> 4. Noding and indexing are the harder half. The existing Envelope
> and MonotoneChain candidate pruning is planar, so it is not
> geodesic-safe: a planar envelope does not bound a geodesic
> segment near the poles or across the antimeridian. Making this
> genuinely usable needs a geodesic-aware Noder and index, which
> is a much larger change than the intersection primitive itself.
> Is that a direction JTS would entertain, or is it too large?
That is the real step, and it belongs in jts-geography. A planar
envelope does not bound a geodesic near a pole or the antimeridian. A
segment-segment primitive in jts-core would teach the wrong stack
about the wrong surface.
This is related to the old SQL/MM curve discussion, but it is not the
same problem. A CIRCULARSTRING still lives on the planar sheet. A
geodesic on WGS84 does not.
The first decision is whether JTS wants that second model at all. If
yes, the place for your prototype is jts-geography, not a PR against
the planar noder.
Best regards,
Jeroen Bloemscheer
