|lat||lon||alt||x||y||z||karney lat err||karney lon err||karney alt err||sky lat err||sky lon err||sky alt err||k lat - s lat||k lon - s lon||k alt - s alt|
Bowring BR (1976) Transformation from spatial to geodetic coordinates.which I have not been able to obtain.
Surv Rev 23: 323–327
The Vermeille reference gives the Bowring forumlas and compares the results of the Vermeille method with those of Bowring for a limited number of points and shows errors in height with the Bowring approximations of up to 0.25m. These seem consistent with the magnitude of the differences I found between GeographicLib and ECEF_to_LLA.
The conversion from geographic to geocentric coordinates is straightforward. For the reverse transformation we use
- H. Vermeille, Direct transformation from geocentric coordinates to geodetic coordinates, J. Geodesy 76, 451–454 (2002).
Several changes have been made to ensure that the method returns accurate results for all finite inputs (even if h is infinite). The changes are described in Appendix B of
Heikkinen M (1982) Geschlossene Formeln zur Berechnungand says
ra¨ umlicher geoda¨ tischer Koordinaten aus rechtwinkligen Koordinaten.
Z Vermess 5: 207–211
Borkowski (1987), (1989), Heikkinen (1982) andJoesef cites two presentations
Lapaine (1991) have proposed their own solutions
based also on an equation ofdegree 4. The resulting
formulae are more complicated than the method
(2) http://www.fsd.mw.tum.de/Homepage-Daten/Lehre%20WS11-12/FSD1/FSD_I_Trafo_WGS.pdf(1) appears to follow Bowring. (2) appears to follow Heikkinen, but I am not able to read German.
in an area of a variation in
lat/lng/alt of 0.177277/0.162193/394.858827
Hi Steve, hi Robert, Am Fr, 4.01.2013, 03:32 schrieb tsteven4:I wrote a test driver to compare lla2ecef from skytraq.c with the Forward method of GeographicLib::Geocentric. I used approximately uniform distributions of: 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 minimum difference (m) -3.72529E-09 -7.68341E-09 -6.51926E-09 maximum difference (m) 5.82077E-09 7.33417E-09 6.51926E-09 mean difference (m) 2.21595E-10 -9.21225E-12 3.29291E-11 standard deviation of difference (m) 1.22922E-09 1.25931E-09 3.84619E-09 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. Stevethanks for trying that out! I agree there's no need to replace this code with GeographicLib (at least not unless the lib might be incorporated anyway someday). Did you also try the other direction ECEF_to_LLA()? In fact, that's the conversion Josef put on discussion afair.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.the reason for my previous mail was to a) just mention that skytraq might be a candidate to profit from GeographicLib, so if it would turn out someday that there are several modules which will use it one can decide whether it's worth incorporating it then. And b) as a reminder to myself to try it once I find the time to investigate the conversion ;-)Didn't we go through several different formulas for ECEF to WGS84 a year or so ago?Hmm, don't remember that, at least not that we found a conclusion. I do have that conversion on my list of things to check since the first release though...Oh, and we do use WGS-84 as that's by far the most common.Regards, MathiasOn Mon, Dec 31, 2012 at 1:11 AM, Mathias Adam <email@example.com <mailto:firstname.lastname@example.org>> wrote: Hi, 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 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. 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 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