[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/