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 <> wrote:

Am So, 30.12.2012, 20:12 schrieb Robert Lipe:
>> I remain incredibly impressed with GeographicLib.  The documentation,
references, and methodology are some of the finest I have ever seen in
>> software package.  I thought it was
> It's well regarded.  I'm just not sure it solves interesting problems
> us.   The huge percentage of the data we target is WGS84.  If you look
> 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
> 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
> more.

After reading about this library here, I took a quick look at its
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

Now, GeographicLib claims to provide an ECEF conversion:

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,