Register package?

[tclements]

Following up on https://github.com/anowacki/Geodesics.jl/issues/3 and https://github.com/JuliaGeo/Geodesy.jl/issues/40 - are you considering registering this package?

(@v1.4) pkg> add GeographicLib
ERROR: The following package names could not be resolved:
 * GeographicLib (not found in project, manifest or registry)

[disberd]

I am commenting just to bump up, but it will be really convenient to have this packages in the General registry

[anowacki]

Apologies not have responded to this before—for some reason I missed that this issue had been created.

I'm not completely averse to registering this port of GeographicLib, but the reasons I haven't yet are mainly that I have planned for a long time to include the functionality in Geodesy. I also am not really completely satisfied with the port, since much of the code is not at all idiomatic Julia.

That said, I am open to persuasion and I can see some utility in having a registered GeographicLib port available for those who don't want to use Geodesy.

[tclements]

Looking back through https://github.com/JuliaGeo/Geodesy.jl/issues/40, I like @c42f's suggestions to include forward and inverse calculations between two points into Geodesy.jl and giving those methods more specific names (geodesic_distance?). Including the line and polygon methods (great work!) from GeographicLib into Geodesics will probably need further discussion, as that would expand the scope of the Geodesics from working with points.

[anowacki]

I am minded to add the functionality of this package to Geodesics.jl and register that instead. Comments and suggestions welcome.

[adigitoleo]

I'm hesitant to mention this because I don't know how quickly it will happen, but I'm thinking of implementing (tele)seismic ray tracing in Julia, probably for 1D models (SeisModels) first. For this purpose it will be useful to have the distance and forward/inverse calculations whereas I probably won't need the rest of Geodesy.jl

However, it could make things confusing if the Julia Proj package is revived or merged with Geodesy.jl. The original GeographicLib also implements the transformations from what I understand, so I would avoid that name in this case. Is there other functionality planned for the merged pagkage outside of what GeodSolve does?

Another idea: How about just wrapping the original GeographicLib with some ccalls? I'm aware of Proj4.jl, but perhaps maintaining a smaller wrapper library would be more feasible. The frontend could be made more Julian (like you've done with GeographicLib). Or does diverging from the original GeographicLib make sense?

[adigitoleo]

Looks like the JLL is already there: https://github.com/JuliaPackaging/Yggdrasil/pull/3587

As well as another one which seems focused on wrapping gravity/magnetic models API: https://github.com/JuliaPackaging/Yggdrasil/pull/3590

Used by https://github.com/twadleigh/GeographicModels.jl

[anowacki]

@adigitoleo as you point out, geodesic calculations are already possible via the libraries included with Proj.jl, so there has always been the possibility of calling Charles Karney's routines via ccall.

The main person who has been working on bringing geodesic distance calculations into Geodesy.jl was me, so I don't think there is too much risk of that happening separately from the effort mentioned in the linked discussion above.

The benefits of creating a pure-Julia solution I think slightly outweigh the downsides, and I also like the idea of moving away from the C/Python interfaces in GeographicLib.

For this purpose it will be useful to have the distance and forward/inverse calculations whereas I probably won't need the rest of Geodesy.jl

It's for this sort of thing that I wanted to create a geodesic distance package. Not wrapping Proj or GeographicLib directly I think would be helpful rather than a hindrance, since any of your custom number types would work and you can choose how accurate versus fast you want the calculations to be. So hopefully an updated GeoDistances.jl (or whatever) will be useful.

[adigitoleo]

The benefits of creating a pure-Julia solution I think slightly outweigh the downsides

I briefly played around with the JLL and now I agree, maintaining the C++ bindings is not trivial and blows up the package size (we would need to depend on the whole GeographicLib binary, much of which would go unused). My only concern is around incorporating upstream changes, since upstream is still actively maintained (last commit June 2021). But I think it's feasible. I like GeoDistances.jl as the name.

[anowacki]

I agree about upstream changes—I will resolve to try and keep on top of those and incorporate them in the Julia codebase.

Thanks for the feedback on the name!

[haakon-e]

Hi @anowacki. First of all, great package! I'm really interested in this for more accurate computations of earth distances -- and related computations (primarily calculating intersection of geodesics).

How far along are you with potential plans for a pure julia implementation? Depending on your plans/progress, I may be interested to try doing that.

[anowacki]

Hi @haakon-e. Thanks for your interest! I have a draft implementation locally that I can push to a branch here if you wanted to build on that and finish this up. It simply brings in the code from GeographicLib.jl. If you need Karney's algorithm in the meantime, you can use GeographicLib.jl, though that isn't registered either.

Right now this package is focussed on distances, but if you wanted to extend it for intersections and other spherical problems I'd be happy to have those things here.

[haakon-e]

@anowacki yes, I'd be interested in that, but no rush. I will most likely have time to put in some good effort in late November / early December. So far things seem to be working with installing this GitHub repo directly.