Geodesics/great circle distances

[anowacki]

I am not a geodesist (just a geophysicist), but have a currently unregistered package, Geodesics.jl which only implements Vincenty's algorithm to compute great circle distances and forward and backazimuths on a flattened sphere, plus adds some convenience functions. (Due credit: the code is not much altered from its source, GreatCircle.jl, by @acrosby.)

Would you like to adopt this into Geodesy.jl? I'm happy to refactor into whatever form and change the API to better match the standards used here. Note that adding ‘true’ distances which take altitude into account is probably beyond my pay-grade.

My main interest lies in this functionality existing in a registered, supported package so I can rely on it for my future seismic applications. (Currently I duplicate the code into, e.g., SAC.jl.) Hence, if there isn't much appetite for something in this form being added to Geodesy.jl soon, I will probably register my Geodesics.jl package instead.

Edited to add: I realise that GeographicLib does all this, but I saw that Proj4.jl is not intended to become a Geodesy.jl dependency. I guess one might instead want a separate geodesics package which dies rely on Proj4.

[acrosby]

This is nicely done (https://github.com/anowacki/Geodesics.jl). I agree that inclusion of these methods into https://github.com/JuliaGeo/Geodesy.jl would be ideal, but at least function call support for the https://github.com/JuliaGeo/Geodesy.jl types would be a good start. I don't have the funding to support a frequent release schedule for https://github.com/acrosby/GreatCircle.jl, at least before Julia 1.0 shows up.

Note that I found a bug in the Python implementation of the great circle distance for nearly antipodal points, that may also impact the Julia implementation(s). (https://github.com/axiom-data-science/pygc/issues/4)

@anowacki I would be happy to deprecate my library if you want to release yours into the package management system (and focus efforts into one place) if that's what you end up doing. The prebuild change you made in https://github.com/acrosby/GreatCircle.jl seemed to have broken some down stream builds for me, but I never looked into why although thats why I didn't push a new release.

Also I see that email replies to not support markdown--super annoying.

[yeesian]

To my limited understanding, this package already ports some of the functionality from GeographicLib, so it might be a matter of finding the right datum to correspond to the desired computations. The ellipsoids already store the corresponding values of a and f you use. Here are the forward and reverse projections.

Perhaps it can do with better documentation and examples?

[yeesian]

Here are the forward and reverse projections.

I was wrong, I'm sorry. I think it'll be a great addition to this package for the methods (forward, inverse, azimuth, etc) in your Geodesics package to be implemented here, failing which you should register it as a package -- it is well written!

[andyferris]

Yes, I geodesic calculation has always been a desired feature for this package. From my perspective, a PR working this into here would be quite welcome.

[anowacki]

Okay, thanks for getting back. I'll find some time to work this into a suitable form and get a PR in.

@acrosby Vincenty actually points out that near-antipodal points will not converge in his paper, and I believe this is fairly well known. I may investigate implementing the method in GeographicLib described by Karney.

[acrosby]

@anowacki Thanks, I never looked at the source paper. I'll loop @kwilcox in so that he is aware

[andyferris]

Yeah, a direct source translation from geographic lib has worked for me in the past.

[anowacki]

I have taken up @andyferris's suggestion and implemented a subset of the geodesic calculations in GeographicLib in GeographicLib.jl (forward and inverse). (I got frustrated with Vincenty's algorithm.) Testing using Charles Karney's testing dataset shows the Julia version to be as accurate as the library provided with Proj. It is a literal port of the Python version with reference to the C version. The 'Julia-style' interface is very much preliminary and I am happy to change it completely.

Hence I think the distance computations are ready for inclusion in or use by Geodesy.jl. I have some questions:

1. Which makes more sense/is more preferable to you: i. Inclusion of the GeographicLib.jl module/code within Geodesy.jl? ii. Dependency on a registered version of GeographicLib.jl?
2. How would you suggest changing the public interface, or does it look acceptable?

Mainly with some idea about (1), I can then add distance functions taking Geodesy.LLAs, Geodesy.ECEFs, etc. either to the package or make a PR.

If registering the package makes sense, then I would approach @kshramt to see if they were happy to cede the name. Or alternatively another name could be used. (E.g., SphericalGeodesics, GeoDistance—suggested by @tclements.)

Part of my motivation is that some people would like to depend on a registered great circle computation package (https://github.com/anowacki/Geodesics.jl/issues/3, but I don't like Vincenty's algorithm much any more). I don't mind if that's one I control or Geodesy.jl (and indeed would prefer the latter).

[c42f]

There is nothing meaningful in @kshramt's repository - looks like it never got beyond planning. So I think you could take that name without worrying.

As for having Geodesy and GeographicLib separately, I think it could make sense if we can identify a distinct purpose for the two libs. If not, I think it would be nice to integrate the work in here and just make you a collaborator on this repo.

Some API thoughts:

• I'd rather not export generic names like forward and inverse unless those names come with extremely generic semantics to match. I'd use more specific names instead.
• I think the Geodesic constructor (and possibly part of the representation) should use Geodesy ellipsoids to allow for standard ellipsoids to be reused.
• Geodesic itself seems like it could be named better; it's not a geodesic but rather a cache of parameters which makes geodesic computations faster (if my rusty memory serves).

[c42f]

Also I somehow forgot to say - thanks for the great work; I think it will be valuable to have here, and you've chosen an excellent library (GeographicLib) to be inspired by.

[anowacki]

Thanks, @c42f, for your helpful comments and suggestions. I'll take this as a sign to prepare a PR incorporating great circle distance calculations and we can take things from there.