[Top][All Lists]

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

[Octave-patch-tracker] [patch #9958] [octave forge](mapping) gcxgc

From: Philip Nienhuis
Subject: [Octave-patch-tracker] [patch #9958] [octave forge](mapping) gcxgc
Date: Mon, 10 Aug 2020 08:00:06 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48

Follow-up Comment #18, patch #9958 (project octave):

It occurred to me that finding the polar axis for any great circle defined by
a (Lat, Lon, Azimuth) trio is actually very easy, but involved.

0 Find intersection with the equator (Lat 0, Lon 0, azi = 90).
0 Get Lon values halfway between the intersections, and define great circle
through those points and the N- an S-poles.
0 Find intersection point between original great circle and the last great
circle found in step 2; that's where the azimuth of the orig. great circle =
exactly 90 degress, or E-W. Add 90 degrees to found Lat (wrap around 180
degrees or pi if needed & also wrap Lon around 360 or 2.pi), then the
resulting (Lat, Lon) = coordinates of intersection of polar axis with sphere.
0 Convert that to ECEF if needed.
0 But, computing inner products may not even be needed, a simple comparison of
(Lat, Lon) values + antipodes would do.
There are probably several optimizations and shortcuts possible.

If your original gcxgc is more accurate than the one based on converting to
ECEF (XYZ), see comment #8, it might be worth pursuing this way; at least to
know how much more accurate the answers would be; obviously there's a
trade-off as regards overall performance. If you want/agree I'll give it a try
when I find a spell.


Reply to this item at:


  Message sent via Savannah

reply via email to

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