Hi all,
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. I have a working prototype, but I would
rather settle the scope question before investing further.
## What it does
Intersection of two finite shortest geodesic segments on an ellipsoid (WGS84 by
default), returning the intersection point together with its position along each
segment. Coordinates follow the JTS convention (x = longitude, y = latitude).
The motivation is that JTS currently has no ellipsoidal support at all. Users who
need geodesically correct predicates today either reproject, accept planar
approximation errors, or leave JTS for GeoTools / spatial4j.
## Current state, honestly
The geodesic engine is solid. The intersection algorithm on top of it is not yet.
I implemented the direct and inverse geodesic problems from scratch, following
Karney (2013), "Algorithms for geodesics", J. Geodesy 87(1), 43-55
(doi:10.1007/s00190-012-0578-0), specifically so that no third-party dependency is
needed. It is validated against GeographicLib-Java, which is a test-scope
dependency only. Over roughly 1.2 million randomized cases:
regime distance agreement azimuth agreement
general (uniform) 1.0e-06 m 2.9e-11 deg
nearly antipodal 5.6e-08 m 1.9e-11 deg
nearly equatorial 5.6e-08 m 3.0e-11 deg
nearly meridional 7.5e-07 m 2.9e-11 deg
No non-convergence and no NaN anywhere, including the antipodal region where the
classical Vincenty inverse fails. (For separations below a few centimetres the
azimuth disagrees more, but that is inherent: perturbing an endpoint by one ULP
swings GeographicLib's own answer by up to 79 degrees there.)
The whole thing compiles under --release 8 with only jts-core on the classpath,
matching what jts-core itself targets. It is about 1150 lines and does not include
the area/polygon parts of GeographicLib, which are not needed here.
The intersection algorithm itself still has real accuracy gaps, which I am working
on and would not propose merging in its current state: it currently misclassifies
a meaningful fraction of crossings as ambiguous, and for nearly parallel segments
it can return a confident point that is badly wrong. I mention this so the state
of the work is clear, not because I am asking anyone to review it yet.
## The questions I actually need answered
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.
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?
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.
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?
Depending on the answers I am happy to reshape this, split it, or drop it.
Thanks for any guidance.
Dietmar Burkard
_______________________________________________
jts-dev mailing list
jts-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jts-dev
