i) latitude from -90 to 90 deg

ii) longitude from -360 to 360 deg

iii) elevation from -9000 to 9000m

I also changed lla2ecef to use doubles instead of long doubles. I also changed a few integer constants to double constants, e.g. 1 -> 1.0, but that's just me. The results, for a 10,000 point simulation, are

x y z

Thus, for psuedo random data:

1) The differences between GeographicLib and lla2ecef are irrelevant for us.

2) there is no need to use long doubles in lla2ecef.

Perhaps there is some pathological input that would show a greater difference, but I don't think lla2ecef explains the bug report Mathias cited.

Steve

main(int argc, char* argv[])

{

double lat, lng, alt;

double ecef_x;

double ecef_y;

double ecef_z;

double ecef_x2;

double ecef_y2;

double ecef_z2;

int idx;

srand((unsigned)(time(0)));

for (idx=0; idx<10000; idx++) {

lat=2.0*90.0*((double)rand()-(double)RAND_MAX/2.0)/(double)RAND_MAX;

lng=2.0*360.0*((double)rand()-(double)RAND_MAX/2.0)/(double)RAND_MAX;

alt=2.0*9000.0*((double)rand()-(double)RAND_MAX/2.0)/(double)RAND_MAX;

GeographicLib_Geocentric_Forward(lat, lng, alt, &ecef_x, &ecef_y, &ecef_z);

//printf("GeographicLib: %f %f %f\n", ecef_x, ecef_y, ecef_z);

lla2ecef(lat, lng, alt, &ecef_x2, &ecef_y2, &ecef_z2);

//printf("syktrak : %f %f %f\n", ecef_x2, ecef_y2, ecef_z2);

printf("%.15f,%.15f,%.15f,%.15f,%.15f,%.15f,%.15f,%.15f,%.15f\n",lat,lng,alt,ecef_x,ecef_y,ecef_z,(ecef_x-ecef_x2),(ecef_y-ecef_y2),(ecef_z-ecef_z2));

}

}

void lla2ecef(double lat, double lng, double alt, double* ecef_x, double* ecef_y, double* ecef_z)

{

double n;

double a = 6378137.0;

double esqr = 6.69437999014e-3;

double s;

double llat, llng, lalt;

llat=lat*M_PI/180.0;

llng=lng*M_PI/180.0;

lalt=alt;

s=sin(llat);

n = a / sqrt(1.0 - esqr * s*s);

*ecef_x = (n+lalt) * cos(llat) * cos(llng);

*ecef_y = (n+lalt) * cos(llat) * sin(llng);

*ecef_z = (n*(1.0-esqr) + lalt)* sin(llat);

}

On 1/3/2013 7:18 PM, Robert Lipe wrote:

It might make an interesting comparison point, but I'd still rather not pull it in if it's "just" a bug fix in a formula for one format.

Didn't we go through several different formulas for ECEF to WGS84 a year or so ago?

Oh, and we do use WGS-84 as that's by far the most common.

On Mon, Dec 31, 2012 at 1:11 AM, Mathias Adam <m.adam--gpsbabel-code@adamis.de> wrote:

Hi,

Am So, 30.12.2012, 20:12 schrieb Robert Lipe:

>> I remain incredibly impressed with GeographicLib. The documentation,After reading about this library here, I took a quick look at its

references, and methodology are some of the finest I have ever seen in

a

>> software package. I thought it was

> It's well regarded. I'm just not sure it solves interesting problems

for

> us. The huge percentage of the data we target is WGS84. If you look

at

> the files doing projection conversions, you'll find the formats doing

projection conversion are either centered around paper maps, location

specific, or just into masochism and allowing internal representations

in

> arbitrary projections.

> I would not be unhappy forgetting about most of those projection

conversions and leaving it to tools specializing in such things, like

GeographicLib and Proj.4. I think I'd rather do less projection

than

> more.

documentation: I think it might be helpful for the skytraq module too.

This format does a conversion from ECEF coordinates to gpsbabel's internal

representation (WGS84, if I remember correctly).

The current implementation of this conversion seems to need some

investigation:

<http://old.nabble.com/Help-in-converting-ECEF-%3C-%3E-Lat-Lng-td34134547.html>

Now, GeographicLib claims to provide an ECEF conversion:

<http://geographiclib.sourceforge.net/html/classGeographicLib_1_1Geocentric.html>

I think it's at least worth a try -- and if it turns out to give better

results than my quick "well, seems to work" solution it would be an

additional argument for including this library (as long as the licensing

issue can be sorted out, of course).

Unfortunately I haven't found the time to look into it now (and probably

won't in the next couple of weeks).

Best Regards,

Mathias