scalaz.geo.Coord should return useful azimuth/reverse azimuth for inverse Vincenty #156

Closed
fiadliel opened this Issue Sep 22, 2012 · 6 comments

Projects

None yet

3 participants

@fiadliel

The function inverse (defined in the Coord trait) implements Vincenty's inverse method:
http://en.wikipedia.org/wiki/Vincenty's_formulae

The results returned for (azi, reverseAzi) are:
(0D, 0D)
(180D, 0D)
(0D, 180D)
(Double.NaN, Double.NaN)

It seems to me that it should really return the result of calculating Vincenty's algorithm, e.g.

    (
      atan2(cosu2 * sin(ed.lambda), cosu1 * sinu2 - sinu1 * cosu2 * cos(ed.lambda)).fromRadians[Double],
      atan2(cosu1 * sin(ed.lambda), -sinu1 * cosu2 + cosu1 * sinu2 * cos(ed.lambda)).fromRadians[Double]
    )

I also don't see that it's reasonable to offer different options depending on whether the algorithm converges within 20 steps or not. The most recent iteration (hopefully) offers the most accurate estimation of the values.

Does this seem reasonable? Would you like a patch/pull request along these lines? (I'm not sure what scalaz code submission policies are).

@fiadliel

Hmm. GeodeticCurve's members are azi and reverseAzi; implying that reverseAzi should be 180 - azi.

This isn't as useful as providing both forward azimuths at the start and end of the geodesic segment, but I guess it doesn't fit into the current model. Still, azi should be set appropriately.

@larsrh

Thanks for submitting this report. If you know a fix, feel free to submit a pull request against master. The original author of this code is @tonymorris, so he might be the best person to review changes (although this module saw the last update three years ago).

@fiadliel

I've been occasionally thinking about this bug report since I filed it; it's only after it was filed that I realized that scalaz-seven has had the Geo support removed, so this report doesn't really matter so much.

Has anybody considered resurrecting the code in another repository, considering that it will be disappeared from the main branch RSN? Maybe that's the real project, if it hasn't already been done. I should probably ask on the mailing list...

@larsrh

It still matters for master, since we are planning to publish a maintenance release 6.0.5 some time after Scala 2.10 is out. Hence, if you know a fix, it will probably incorporated.

@larsrh

Closing all 6.0.x-related bugs, because there is nobody maintaining it.

@garycoady, if you're still interested in getting this fixed for 7.0.x, please file the bug over at the scalaz-geo. I can't guarantee that somebody will take care of it, though.

@larsrh larsrh closed this Feb 1, 2014
@tonymorris
Scalaz member

FWIW, I use Haskell for anything to do with geodetic programming and much of this particular library has recently been updated and is quite different to the original port.

http://hackage.haskell.org/package/geodetic
http://hackage.haskell.org/package/coordinate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment