Clarify that current cross-track distance uses spherical (Haversine) earth model, add Ellipsoidal (Vincenty) version

[nrhill1]

Issue #1128

In response to Issue #1128 , I moved the old cross_track_distance.rs into a new cross_track_distance_haversine.rs file and added an ellipsoid cross track distance function in cross_track_distance_geodesic.rs that uses the Karney 2023 improvements to the BML algorithm on geodesic intersections.

[busstoptaktik]

Conceptually, I think this material would work better as a trait implemented for the Geodesic struct. As an example, I have a draft of a very different (and most likely much worse) cross-track-distance approach over at Geodesy, where it is implemented for the Ellipsoid struct (and Geodesic is really just a glorified Ellipsoid).

It would allow the functionality to work for any ellipsoid, not just the WGS84, which you constrain it to here, and it would eliminate the (rather heavy) recomputation of all the numerical factors for Geodesic at every new call.

That said, I'm just a humble hangaround, not a member of the Georust gang, so the real georusters may have a different view of this

[nrhill1]

@busstoptaktik -- Interesting take, Thomas. I am, however, struggling to find the Geodesic struct in this crate so that I can understand your point a little better.

[busstoptaktik]

struggling to find the Geodesic struct in this crate so

I'm talking about the Geodesic struct from geographiclib_rs, which you use in your code

[nrhill1]

So @busstoptaktik; are you suggesting we put these as a trait implementations in geographiclib_rs?

[busstoptaktik]

are you suggesting we put these as a trait implementations in geographiclib_rs?

Since geographiclib-rs is a hard dependency anyway, and since it extends it with material based on additional work by the original author of GeographicLib, I think it would be a reasonable place to put it.

Also note that it would be meaningful (e.g. for roundtripping), and probably almost free, to return a tuple consisting of the across track distance in combination with the along track distance for the intersection.

[michaelkirk]

Thank you for the code and sorry that this sat here for so long!

ses the Karney 2023 improvements to the BML algorithm on geodesic intersections.

Is this based on reading a paper or on existing code somewhere? Can you provide a link to either or both?

it would eliminate the (rather heavy) recomputation of all the numerical factors for Geodesic at every new call.

Note that Geodesic::wg84() is memoized, so it only incurs that setup cost one time.

@busstoptaktik's larger point about being able to use the method on other geodesics is reasonable, but in any case, I think we'll still want this existing API as well, because it mirrors our Haversine implementation, so I think it makes sense to merge this.

(I still do want to update the docs and compare to any reference implementation you can link before merging)

[nrhill1]

Hi @michaelkirk, thanks for joining us!

I've implemented the ellipsoidal formula based on the following Python code
which is related to the changes in this Karney 2023 paper, as well as an existing Rust implementation from Catenary.

[michaelkirk]

Sorry that this once again sat here so long.

The bad news is, I think it no longer makes sense to merge this PR as phrased.

The good(?) news is that this issue, and several like it, caused me to reorganize our various measurement traits to avoid ambiguity in the underlying metric system (is it Haversine? Euclidean? Ellipsoidal?) and also to make it easier to express some generic implementations that work across metric systems (e.g. Rather than having a EuclideanDensify and HaversineDensify , the new Densify trait is implemented generically for anything that implements Distance + InterpolatePoint, so along with Euclidean, Haversine, we got Geodesic and Rhumb for free too.

Would you be willing to port CrossTrackDistance to this to the new regime?

This is what needs to be done:

1. move the legacy haversine implementation to HaversineMeasure.cross_track_distance
2. #deprecate the legacy API and point users to HaversineMeasure.cross_track_distance

And then either:

3a. move your new geodesic version (thank you!) to GeodesicMeasure.cross_track_distance

or if it makes sense :

3.b. express this algorithm generically for, so that both measurement systems can share an underlying implementation. That'd be neat, but it's not necessary, and I'm not familiar enough with the underlying algorithm to know if it's reasonable.

You opened this PR over a year ago, yikes! I'd understand if you're over it at this point. Let me know if you're over it and I can take it over.

[nrhill1]

@michaelkirk I think at this point it's better I redo it completely from a different branch? Or if you have time and want to take over, that's totally cool.