-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Great circle calculations #53
base: master
Are you sure you want to change the base?
Conversation
- Document GreatCircle in README. - Export GreatCircle - Move geodesics to their own source file - Add tests - Add GeographicLib code directly to the source tree. This does not contain GeographicLib.jl tests.
Great to see! I think it would be fine to copy the source of your As for API, how do we name As for the set of function calls we support for use with
These are just suggestions. The general theme here is to name functions according to what they do rather than how they do it. This is kind of the opposite of the approach taken in Naming is hard as always. I think for the set of geodesics and an individual geodesic |
Thanks very much, Chris! I will take this on board and push something with these suggestions incorporated. Apologies that it will not be immediately. Just to explain how I got started on the initial interface: I took inspiration from the syntax for transformations, where e.g. a
Having a plural as a package name which provides a type (e.g.,
I can't argue with Degrees are used for coordinates (longitude-latitude) in Geodesy, so it seems consistent to stick to that for angular quantities here, in my opinion, rather than radians. Is the current approach of distinguishing between input arc distance and geodesic distance via keyword argument not helpful here? I agree making the input unitful would not be ideal.
Here, you're constructing a cache for a particular 'geodesic line', so the question is then what do you want from it, I suppose. Assuming
These paths aren't circles at all because we're on an ellipsoid, naturally, so we should probably avoid I don't really know which is more or less correct, but to me constructing a Other computed valuesOne of the reasons that I implemented GeographicLIb.jl the way I did was because each forward or inverse calculation gives you several values (forward and backazimuth, geodesic and arc distance, etc.) Having functions like |
It strikes me now that much of this naming problem would go away if we just stored the precomputed cache needed for the geodesic calculations in each It would require adding extra fields to the struct and ellipsoid creation would be slower, but creating ellipsoids is rare in Geodesy anyway. Built-in datums/ellipsoids would then just be used for the p1, p2 = LLA(0, 0, 0), LLA(1, 1, 0)
azimuth(p1, p2, wgs84)
geodesic_distance(p1, p2) # datum assumed to be wgs84 like in distance? A Thoughts? (Edit: |
Yes, this is the style from
Having the public API based on an geodesic_distance(e::Ellipsoid, ll1, ll2) = geodesic_distance(GeodesicCache(e), ll1, ll2)
GeodesicCache(e::Ellipsoid) = some_hopefully_pure_enough_stuff # Maybe with a sprinkling of Base.@pure
Sure, my list was just a representative example, not meant to be exhaustive.
Yes of course; degrees for consistency. Keyword args are probably fine for this too, and may also be worth using those for azimuth just for clarity.
Though technically inaccurate, I don't think it's too bad. Accessibility of terminology is a good thing. I could still go either way here.
For sure: we should have some function to return all the values which are byproducts of the calculation, rather than recomputing them multiple times. Perhaps that would be a lower-level function which is named according to the technicalities (geodesic_direct / geodesic_inverse etc). A named tuple return for that seems pretty ok to me. |
To expand, I do really like the idea that the user only need specify the Ellipsoid (or Datum from which the ellipsoid can be extracted). Though I don't think this implies that we should stash coefficients in the Ellipsoid itself. Hopefully we can get the compiler to constant fold some things as mentioned above.
I'd write as
because the ellipsoid is a context for the calculation and I think it's fair to say that context objects are ususally put first in Julia. (This allows the position of the context to be fixed, where the other arguments may change in type or number.)
Yes, that's rather tempting, perhaps we should allow a default.
I'm not sure I quite understand this comment. |
Some initial testing suggests that it'll be hard to get the compiler to do the constant propagation, but I will persevere.
Me too, but currently one does
That's a good idea—let's go with that.
I just meant that the singular |
Oh right. It's so long since I tried actually using this package that I forgot about that 😬. TBH at this stage I'm still paying some attention to I do think it would be completely fine to deprecate that version of |
I am just implementing mm-accuracy great circle calculation myself from original Vincenty/Karney papers. Happy to contribute code if there is still need. |
@bridgewalker This is great to hear. You probably know that I ported Karney's GeographicLib as the basis for this PR (which I clearly haven't advanced for some time). You are welcome to use that, base your work on it, or if you have the time and interest, update this PR or make a new one based off your own work. In the end, I'm just interested in getting geodesic distances into Geodesy, but other things keep getting in the way. If you were interested in getting this done, I would be delighted for any support you'd like to offer! |
Mine is done and tested. Also implemented some other useful formulas. Still needs integrating with Geodesy though.
|
Great! Are you able to share a link to a repo? Are you interested in taking forward this or another PR adding geodesic calculations? |
Yes happy to contribute some more. Just working on a fast "Point in
polygon" check. But fairly new to githup.
So I guess the best way to get my code up is to create a new branch?
So I should have a proper file that links for you that links to Geodesy in
a few days.
…On Mon, 17 Aug 2020 at 15:56, Andy Nowacki ***@***.***> wrote:
Great! Are you able to share a link to a repo? Are you interested in
taking forward this or another PR adding geodesic calculations?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#53 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQSHVRECPAUZXNCPM7JCFCDSBEZKNANCNFSM4I4OWU7A>
.
--
Prof. Dr. Thilo Gross
Professor of Biodiversity Theory
Universität Oldenburg / HIFMB
reallygross.de / biond.org
|
This is a very draft implementation of great circle calculations for Geodesy. Suggestions for improvement very warmly welcomed.
There are a number of things which need to be addressed before this could be merged:
(::GreatCircle)(point, azi, dist)
) should probably return a point of the same type as input, but how should this be done when also returning backazimuth, distance and angular distance?