From: Mathias Adam <m.adamgpsbabelcode@ad...>  20121231 07:12:25

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/HelpinconvertingECEF%3C%3ELatLngtd34134547.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 
From: Robert Lipe <robertlipe@gp...>  20130104 02:18:48
Attachments:
Message as HTML

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 WGS84 as that's by far the most common. On Mon, Dec 31, 2012 at 1:11 AM, Mathias Adam < m.adamgpsbabelcode@...> 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/HelpinconvertingECEF%3C%3ELatLngtd34134547.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 > > > 
From: tsteven4 <tsteven4@gm...>  20130104 02:33:07
Attachments:
Message as HTML

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.72529E09 7.68341E09 6.51926E09 maximum difference (m) 5.82077E09 7.33417E09 6.51926E09 mean difference (m) 2.21595E10 9.21225E12 3.29291E11 standard deviation of difference (m) 1.22922E09 1.25931E09 3.84619E09 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_xecef_x2),(ecef_yecef_y2),(ecef_zecef_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.69437999014e3; > 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.0esqr) + 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 WGS84 as that's by far the most common. > > > On Mon, Dec 31, 2012 at 1:11 AM, Mathias Adam > <m.adamgpsbabelcode@... > <mailto:m.adamgpsbabelcode@...>> 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/HelpinconvertingECEF%3C%3ELatLngtd34134547.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 > > > 
From: Mathias Adam <m.adamgpsbabelcode@ad...>  20130104 12:00:26

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.72529E09 7.68341E09 > 6.51926E09 > maximum difference (m) 5.82077E09 7.33417E09 > 6.51926E09 > mean difference (m) 2.21595E10 9.21225E12 > 3.29291E11 > standard deviation of difference (m) 1.22922E09 1.25931E09 > 3.84619E09 > > 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 thanks 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 WGS84 as that's by far the most common. Regards, Mathias >> >> >> On Mon, Dec 31, 2012 at 1:11 AM, Mathias Adam >> <m.adamgpsbabelcode@... >> <mailto:m.adamgpsbabelcode@...>> 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/HelpinconvertingECEF%3C%3ELatLngtd34134547.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 >> >> >> > > 
From: tsteven4 <tsteven4@gm...>  20130105 15:43:31
Attachments:
Message as HTML

Mathias, Thanks for pointing out the reverse conversion is the one in question. The results are: 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 min 2.1E14 3.67254E09 9E06 0.99846 8.9E06 2.8E14 3.51E06 max 2.1E14 3.68982E09 8.94E06 3.5E06 9.05E06 2.8E14 0.998459 mean 2.3E18 3.85265E12 2.1E08 0.3197 2.11E08 6.46E17 0.3197 std. dev. 3.85E15 9.30808E10 3.67E06 0.256233 3.67E06 8.09E15 0.256233 The method was to pick psuedo random (lat,lon,alt) points as before, convert to ecef (x,y,z) via GeographicLib (which was previously shown to be well matched with lla2ecef), and then do the reverse transform either via GeographicLib (karney lat err, ...) or ECEF_to_LLA (sky lat err, ...). The columns karney lat err, ... sky lat err, ... are the difference between the reverse transform output and the original (lat, long, alt) data. The final 3 columns are the difference between the karney and skytraq (ECEF_to LLA) reverse transform output. I didn't summarize the longitude differences because the longitude is easy to compute in the reverse transform, the errors are small, and I would have had to clean up 360 degree reporting differences. The units I used are degrees and meters. As I would expect the reverse transform in GeographicLib gives us the back the original point with a very high degree of accuracy, all differences were less than 4nm. ECEF_to_LLA showed errors up to 1m. I point out that there are errors of similar magnitude in latitude with ECEF_to_LLA. From my reading of the original works ECEF_to_LLA appears to be based on > Bowring BR (1976) Transformation from spatial to geodetic coordinates. > Surv Rev 23: 323327 which I have not been able to obtain. The excellent documentaion of GeographicLib states > > 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 > <http://dx.doi.org/10.1007/s0019000202736>;, J. Geodesy 76, > 451454 (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 > > * C. F. F. Karney, Geodesics on an ellipsoid of revolution > <http://arxiv.org/abs/1102.1215v1>;, Feb. 2011; preprint > arxiv:1102.1215v1 <http://arxiv.org/abs/1102.1215v1>;. > 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. Vermeille also cites > Heikkinen M (1982) Geschlossene Formeln zur Berechnung > ra¨ umlicher geoda¨ tischer Koordinaten aus rechtwinkligen Koordinaten. > Z Vermess 5: 207211 and says > Borkowski (1987), (1989), Heikkinen (1982) and > Lapaine (1991) have proposed their own solutions > based also on an equation ofdegree 4. The resulting > formulae are more complicated than the method > described here. Joesef cites two presentations > (1) http://www.joachimbolz.de/projekte/gps/gps.html > <http://www.joachimbolz.de/projekte/gps/gps.html>;, > (2) > http://www.fsd.mw.tum.de/HomepageDaten/Lehre%20WS1112/FSD1/FSD_I_Trafo_WGS.pdf (1) appears to follow Bowring. (2) appears to follow Heikkinen, but I am not able to read German. Josef also says he believes that he thinks the methods (1) and (2) differed in height by approximately 68m. This result is unexpectedly large. It is hard for me to believe that the various solutions Vermeille cites have differences this large, but I haven't compared them or found a reference that does so. I think Vermeille would have pointed out these errors instead of mentioning complexity. I suspect one of the follow may explain this large difference: 1) Josef made a mistake 2) There is an error in (2), perhaps typographic 3) Different assumptions are used in (2) that we haven't appreciated 4) ??? However Josef also states he believes the results from (2) more closely match the results from ntrip and the gpsvisulaizer elevation data base. While I wouldn't consider either of these a primary reference I can't explain the discrepancy. It also unclear to me what points Josef is using for his comparison. Are his points near lat=0.177 (units?), lon=0.162(units ?), alt 395 (presumably m)? > in an area of a variation in > lat/lng/alt of 0.177277/0.162193/394.858827 Is it possible that the gps data Josef used just had large elevation errors? I know my old Garmin has a hard time estimating elevation. At this time I cannot support Josef's desire to change to the method of (2). I don't think the original issue is understood. The methods of GeographicLib could reduce significant but not overwhelming errors, i.e. ~1m, and these differences are explainable as I discussed above, but these are small relative to the original reported issue. It would seem to me that the gpsbabel project could add more value by concentrating on things central to the project like format translations instead of pretending we are geodesy experts, i.e. I think we should build on the work of acknowledged experts in geodesy instead of trying to do it ourselves. However, I still don't have an overwhelming example to support GeographicLib usage although errors approaching 1m seem like something we might want to correct. Steve On 1/4/2013 4:59 AM, Mathias Adam wrote: > 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.72529E09 7.68341E09 >> 6.51926E09 >> maximum difference (m) 5.82077E09 7.33417E09 >> 6.51926E09 >> mean difference (m) 2.21595E10 9.21225E12 >> 3.29291E11 >> standard deviation of difference (m) 1.22922E09 1.25931E09 >> 3.84619E09 >> >> 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 > > thanks 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 WGS84 as that's by far the most common. > > Regards, > Mathias > > > >>> >>> On Mon, Dec 31, 2012 at 1:11 AM, Mathias Adam >>> <m.adamgpsbabelcode@... >>> <mailto:m.adamgpsbabelcode@...>> 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/HelpinconvertingECEF%3C%3ELatLngtd34134547.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 >>> >>> >>> >> > 
From: tsteven4 <tsteven4@gm...>  20130107 13:56:16
Attachments:
Message as HTML

I may be on to the issue Josef reported. To be sure I would need to know the latitude and longitude of Josef's test data. As explained here http://geographiclib.sourceforge.net/html/geoid.html > The gravitational equipotential surface approximately coinciding with > mean sea level is called the geoid. The GeographicLib::Geoid > <http://geographiclib.sourceforge.net/html/classGeographicLib_1_1Geoid.html>; > class and the GeoidEval > <http://geographiclib.sourceforge.net/html/GeoidEval.1.html>; utility > evaluate the height of the geoid above the WGS84 ellipsoid. This can > be used to convert heights above mean sea level to heights above the > WGS84 ellipsoid. Using the egm965 dataset for Berlin the GeographicLib utility GeoidEval computes a difference of 39.49m. While this doesn't match the reported error of 68m I don't know the coordinates Josef used in his test. > % echo '52.5233N 13.4127E'  ./GeoidEval d > $HOME/local/GeographicLib/share/geoids > 39.4934 GeographicLib has a class GeographicLib::Geoid to do this computation that we could utilize (again assuming we could work out the licensing). Steve On 1/5/2013 8:43 AM, tsteven4 wrote: > Mathias, > > Thanks for pointing out the reverse conversion is the one in > question. The results are: > > 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 > > > min > > > > > 2.1E14 > 3.67254E09 9E06 > 0.99846 8.9E06 2.8E14 3.51E06 > max > > > > > 2.1E14 > 3.68982E09 8.94E06 > 3.5E06 9.05E06 2.8E14 0.998459 > mean > > > > > 2.3E18 > 3.85265E12 2.1E08 > 0.3197 2.11E08 6.46E17 0.3197 > std. dev. > > > > > 3.85E15 > 9.30808E10 3.67E06 > 0.256233 3.67E06 8.09E15 0.256233 > > > The method was to pick psuedo random (lat,lon,alt) points as before, > convert to ecef (x,y,z) via GeographicLib (which was previously shown > to be well matched with lla2ecef), and then do the reverse transform > either via GeographicLib (karney lat err, ...) or ECEF_to_LLA (sky lat > err, ...). The columns karney lat err, ... sky lat err, ... are the > difference between the reverse transform output and the original (lat, > long, alt) data. The final 3 columns are the difference between the > karney and skytraq (ECEF_to LLA) reverse transform output. I didn't > summarize the longitude differences because the longitude is easy to > compute in the reverse transform, the errors are small, and I would > have had to clean up 360 degree reporting differences. The units I > used are degrees and meters. > > As I would expect the reverse transform in GeographicLib gives us the > back the original point with a very high degree of accuracy, all > differences were less than 4nm. ECEF_to_LLA showed errors up to 1m. > I point out that there are errors of similar magnitude in latitude > with ECEF_to_LLA. > > From my reading of the original works ECEF_to_LLA appears to be based on >> Bowring BR (1976) Transformation from spatial to geodetic coordinates. >> Surv Rev 23: 323327 > which I have not been able to obtain. > > The excellent documentaion of GeographicLib states >> >> 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 >> <http://dx.doi.org/10.1007/s0019000202736>;, J. Geodesy 76, >> 451454 (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 >> >> * C. F. F. Karney, Geodesics on an ellipsoid of revolution >> <http://arxiv.org/abs/1102.1215v1>;, Feb. 2011; preprint >> arxiv:1102.1215v1 <http://arxiv.org/abs/1102.1215v1>;. >> > 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. > > Vermeille also cites >> Heikkinen M (1982) Geschlossene Formeln zur Berechnung >> ra¨ umlicher geoda¨ tischer Koordinaten aus rechtwinkligen Koordinaten. >> Z Vermess 5: 207211 > and says >> Borkowski (1987), (1989), Heikkinen (1982) and >> Lapaine (1991) have proposed their own solutions >> based also on an equation ofdegree 4. The resulting >> formulae are more complicated than the method >> described here. > Joesef cites two presentations >> (1) http://www.joachimbolz.de/projekte/gps/gps.html >> <http://www.joachimbolz.de/projekte/gps/gps.html>;, >> (2) >> http://www.fsd.mw.tum.de/HomepageDaten/Lehre%20WS1112/FSD1/FSD_I_Trafo_WGS.pdf > (1) appears to follow Bowring. (2) appears to follow Heikkinen, but I > am not able to read German. > > Josef also says he believes that he thinks the methods (1) and (2) > differed in height by approximately 68m. This result is unexpectedly > large. It is hard for me to believe that the various solutions > Vermeille cites have differences this large, but I haven't compared > them or found a reference that does so. I think Vermeille would have > pointed out these errors instead of mentioning complexity. I suspect > one of the follow may explain this large difference: > 1) Josef made a mistake > 2) There is an error in (2), perhaps typographic > 3) Different assumptions are used in (2) that we haven't appreciated > 4) ??? > > However Josef also states he believes the results from (2) more > closely match the results from ntrip and the gpsvisulaizer elevation > data base. While I wouldn't consider either of these a primary > reference I can't explain the discrepancy. It also unclear to me what > points Josef is using for his comparison. Are his points near > lat=0.177 (units?), lon=0.162(units ?), alt 395 (presumably m)? >> in an area of a variation in >> lat/lng/alt of 0.177277/0.162193/394.858827 > > Is it possible that the gps data Josef used just had large elevation > errors? I know my old Garmin has a hard time estimating elevation. > > At this time I cannot support Josef's desire to change to the method > of (2). I don't think the original issue is understood. > > The methods of GeographicLib could reduce significant but not > overwhelming errors, i.e. ~1m, and these differences are explainable > as I discussed above, but these are small relative to the original > reported issue. It would seem to me that the gpsbabel project could > add more value by concentrating on things central to the project like > format translations instead of pretending we are geodesy experts, i.e. > I think we should build on the work of acknowledged experts in geodesy > instead of trying to do it ourselves. However, I still don't have an > overwhelming example to support GeographicLib usage although errors > approaching 1m seem like something we might want to correct. > > Steve > > On 1/4/2013 4:59 AM, Mathias Adam wrote: >> 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.72529E09 7.68341E09 >>> 6.51926E09 >>> maximum difference (m) 5.82077E09 7.33417E09 >>> 6.51926E09 >>> mean difference (m) 2.21595E10 9.21225E12 >>> 3.29291E11 >>> standard deviation of difference (m) 1.22922E09 1.25931E09 >>> 3.84619E09 >>> >>> 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 >> thanks 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 WGS84 as that's by far the most common. >> Regards, >> Mathias >> >> >> >>>> On Mon, Dec 31, 2012 at 1:11 AM, Mathias Adam >>>> <m.adamgpsbabelcode@... >>>> <mailto:m.adamgpsbabelcode@...>> 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/HelpinconvertingECEF%3C%3ELatLngtd34134547.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 >>>> >>>> >>>> > 