octave-patch-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-patch-tracker] [patch #10021] [octave forge] (mapping) meridianf


From: Philip Nienhuis
Subject: [Octave-patch-tracker] [patch #10021] [octave forge] (mapping) meridianfwd
Date: Tue, 27 Jul 2021 16:42:05 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #27, patch #10021 (project octave):

Yeah perhaps private/ is a better place for sph_chk.m to live in.
I've only pushed it yet - a next step is to invoke it in the various functions
that use reference ellipsoids and -spheres.
Something for later this summer, I still don't have that much time for
Octave.

Both vincenty.m and geodeticarc.m have as 2nd output parameter the azimuths at
starting & end points; AFAICS that works quite well. I suppose that the
azimuth of the starting point is what "azimuth.m" computes - can you confirm?
My thinking is that both functions compute the geodesics = shortest
connections between two points, so the azimuths at the starting point should
point in the optimal direction.
>From azimuth.m at Alfredo Foltran's site:

:
## @example
## >> azimuth([10, 10], [10, 40])
## ans = 87.336
## >> azimuth([0, 10], [0, 40])
## ans = 90
## >> azimuth(pi / 4, 0, pi / 4, -pi / 2, "radians")
## ans = 5.3279
:


and current dev mapping package's geodeticarc.m:

>> [a, b] = geodeticarc ([10, 10], [10, 40])
a = 3.2880e+06
b =
   87.336   92.664

>> [a, b] = geodeticarc ([0, 10], [0, 40])
a = 3.3396e+06
b =
   90   90

>> rad2deg ([pi / 4, 0])
ans =
   45    0
>> rad2deg ([pi / 4, -pi / 2])
ans =
   45  -90
>> [~, b] = geodeticarc ([45, 0], [45, -90])
b =
   -54.726  -125.274
>> mean (b)
ans = -90
## makes sense, the entire displacement is due west = -90 degrees
>> deg2rad (b)
ans =
  -0.9552  -2.1864

>> 2 * pi + deg2rad (b)
5.3280   4.0967


so all basic functionality is there.
geodeticarc.m as it stands needs a few improvements:
* allow radians as input
* allow separate lat/lon values as inputs besides [lat lon] vectors/matrices
* apply wrapTo360 / wrapTo2Pi to the azimuth outputs.

Well, something for this summer. Or would you have a go at it?


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/patch/?10021>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]