From: W. eWatson on
I'm doing some coordinate transform work on the earths surface using
lat/long using xyz rotation matrices. So far the results look decent but
concocting test cases and results is a bit tricky. Maybe there's a
software tool that would help?

Here's a simple example I'm working on. x is pointing south, y east and
z through the north pole. I want to pick an arbitrary point and draw a
circle of a radius in degrees around it on the earth.

Suppose I'm content with one point on the circle to make this easy, and
let's take the set up along 0 longitude.

Center of circle: (0.0, 20.0) (long,lat)
Point on circle: (0.0, 30.0)
I want the point on the circle to be 90 deg ccw to the west.

Seemingly, that should be at (-10,20) in the original xyz. But I get
(19.68,-10.63).

Since I'm drawing a circle (one point here) and it is not (after the
"circle" position rotation) on a great circle, the results seem close
enough. Nevertheless, unless I use another method, I may not have
computed these properly. I could change tests to more favorable spots
(center at (0,0), radius point at (0,90)), but it would be good to have
some definitive result to compare.
From: KBH on
Converting to local topocentric moves the pole to the user's location
and that might be related.

Here is KBH code:

{Latitude and longitude to ECEF xyz}
{KBH Code}
ra:= 180 / Pi;
a:= 6378137;
ee:= 0.006694379990;
Write(' Input latitude in degrees: ');
ReadLn(lat);
Write(' Input longitude in degrees: ');
ReadLn(lon);
Write(' Input ellipsoidal height in meters: ');
ReadLn(h);
lat:= lat / ra;
lon:= lon / ra;
v:= a / Sqrt(1 - (ee * Sqr(Sin(lat))));
x:= (v + h) * Cos(lat) * Cos(lon);
y:= (v + h) * Cos(lat) * Sin(lon);
z:= ((1 - ee) * v + h) * Sin(lat);


----------------------------------------------------


{ECEF xyz to local topocentric}
{KBH Code}
nr:= (-x * Sin(lat) * Cos(lon)) + (-y * Sin(lat) * Sin(lon)) + (z *
Cos(lat));
ea:= (-x * Sin(lon)) + (y * Cos(lon));
ht:= (x * Cos(lat) * Cos(lon)) + (y * Cos(lat) * Sin(lon)) + (z *
Sin(lat));


{Note the first input is the lat and lon of the first xyz point
converted to
local topocentric and then that lat and lon is held in the
computations for
all the next xyz input points going to the same local topocentric
system}


-----------------------------------------------------


{ECEF xyz to latitude and longitude}
{KBH Code}
ra:= 180 / Pi;
a:= 6378137;
f:= 0.003352811;
fm:= 1 - f;
ee:= 0.006694379990;
WriteLn;
Write(' Input x coordinate in meters: ');
ReadLn(x);
Write(' Input y coordinate in meters: ');
ReadLn(y);
Write(' Input z coordinate in meters: ');
ReadLn(z);
If (x = 0) Then x:= 0.0001;
{If (x > a) Or (y > a) Then Exit;
If (x < -a) Or (y < -a) Then Exit;}
p:= Sqrt(Sqr(x) + Sqr(y));
r:= Sqrt(Sqr(p) + Sqr(z));
u:= z / p * (fm + (ee * a / r));
u:= ArcTan(u);
lon:= ArcTan(y / x);
la:= (z * fm) + (ee * a * Sin(u) * Sqr(Sin(u)));
lt:= fm * (p - (ee * a * Cos(u) * Sqr(Cos(u))));
lat:= ArcTan(la / lt);
ha:= p * Cos(lat) + (z * Sin(lat));
hb:= a * Sqrt(1 - (ee * Sqr(Sin(lat))));
h:= ha - hb;
lon:= lon * ra;
lat:= lat * ra;
If (x < 0) Then lon:= 180 + lon;
If (lon > 180) Then lon:= lon - 360;


------------------------------------------------------


From: W. eWatson on
On 7/26/2010 5:38 PM, KBH wrote:
> Converting to local topocentric moves the pole to the user's location
> and that might be related.
>
> Here is KBH code:
>
> {Latitude and longitude to ECEF xyz}
> {KBH Code}
> ra:= 180 / Pi;
> a:= 6378137;
> ee:= 0.006694379990;
> Write(' Input latitude in degrees: ');
> ReadLn(lat);
> Write(' Input longitude in degrees: ');
> ReadLn(lon);
> Write(' Input ellipsoidal height in meters: ');
> ReadLn(h);
> lat:= lat / ra;
> lon:= lon / ra;
> v:= a / Sqrt(1 - (ee * Sqr(Sin(lat))));
> x:= (v + h) * Cos(lat) * Cos(lon);
> y:= (v + h) * Cos(lat) * Sin(lon);
> z:= ((1 - ee) * v + h) * Sin(lat);
>
>
> ----------------------------------------------------
>
>
> {ECEF xyz to local topocentric}
> {KBH Code}
> nr:= (-x * Sin(lat) * Cos(lon)) + (-y * Sin(lat) * Sin(lon)) + (z *
> Cos(lat));
> ea:= (-x * Sin(lon)) + (y * Cos(lon));
> ht:= (x * Cos(lat) * Cos(lon)) + (y * Cos(lat) * Sin(lon)) + (z *
> Sin(lat));
>
>
> {Note the first input is the lat and lon of the first xyz point
> converted to
> local topocentric and then that lat and lon is held in the
> computations for
> all the next xyz input points going to the same local topocentric
> system}
>
>
> -----------------------------------------------------
>
>
> {ECEF xyz to latitude and longitude}
> {KBH Code}
> ra:= 180 / Pi;
> a:= 6378137;
> f:= 0.003352811;
> fm:= 1 - f;
> ee:= 0.006694379990;
> WriteLn;
> Write(' Input x coordinate in meters: ');
> ReadLn(x);
> Write(' Input y coordinate in meters: ');
> ReadLn(y);
> Write(' Input z coordinate in meters: ');
> ReadLn(z);
> If (x = 0) Then x:= 0.0001;
> {If (x> a) Or (y> a) Then Exit;
> If (x< -a) Or (y< -a) Then Exit;}
> p:= Sqrt(Sqr(x) + Sqr(y));
> r:= Sqrt(Sqr(p) + Sqr(z));
> u:= z / p * (fm + (ee * a / r));
> u:= ArcTan(u);
> lon:= ArcTan(y / x);
> la:= (z * fm) + (ee * a * Sin(u) * Sqr(Sin(u)));
> lt:= fm * (p - (ee * a * Cos(u) * Sqr(Cos(u))));
> lat:= ArcTan(la / lt);
> ha:= p * Cos(lat) + (z * Sin(lat));
> hb:= a * Sqrt(1 - (ee * Sqr(Sin(lat))));
> h:= ha - hb;
> lon:= lon * ra;
> lat:= lat * ra;
> If (x< 0) Then lon:= 180 + lon;
> If (lon> 180) Then lon:= lon - 360;
>
>
> ------------------------------------------------------
>
>
After I posted this, I started thinking I've got to get from lat/long
into a perhaps spherical coord sys or something like it, and work in it
until I need to get back to lat/long. Right now I do my malformations
using x,y, and z rotation matrices, and sometimes translate back and
forth between xyz and spherical angles. I'm using 3x3 rotational
matrices. I need to be in a spherical system of some sort, I think, to
be able to work with great circles. Maybe topo-centric does that. At
this stage I do not need to account for an oblate sphere.

Yes, it looks like I need to get the center of the circle at 0,0. Right
now I've rotated the center to 0,0 longitude. Distances on a lat/long
system are not equal, so that's probably causing some difficulty. This
needs more thinking on my part. Possibly spherical system with vectors
in spherical form: (phi, theta, r). Something like that. I may not even
need rotational transformations.

Thanks for the code, but I have no idea what to do with it. KBH is code
for what? Something to do with Google maps? This topic is related to
ground stations that scan the skies.
From: Tim Little on
On 2010-07-27, W. eWatson <wolftracks(a)invalid.com> wrote:
> After I posted this, I started thinking I've got to get from lat/long
> into a perhaps spherical coord sys or something like it

Lat/long (and implied radius) is already a spherical coordinate
system.


> Yes, it looks like I need to get the center of the circle at 0,0. Right
> now I've rotated the center to 0,0 longitude.

Since you want to find a circle on the sphere and have said that you
already have the rotation code, it would be much easier to rotate to a
pole where circles are just curves of constant latitude instead of the
equator.


- Tim
From: KBH on

> Thanks for the code, but I have no idea what to do with it. KBH is code
> for what? Something to do with Google maps? This topic is related to
> ground stations that scan the skies.- Hide quoted text -
>
> - Show quoted text -

I was thinking rotate around a pole while working with xyz coordinates
but first move the pole to the lat,lon of 20,0 .

I'm looking for my notes on how the local topocentric code works. The
ECEF xyz code works normally.

But ground stations that scan the sky is a local-topocentric
application.