From: tsteven4 <tsteven4@gm...>  20130107 13:56:16

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