NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
Re: Celestial data for the planet Mercury
From: Paul Hirose
Date: 2016 Feb 23, 21:27 -0800
From: Paul Hirose
Date: 2016 Feb 23, 21:27 -0800
On 2016-02-22 7:03, Dave Walden wrote: > ************************ > http://aa.usno.navy.mil/cgi-bin/aa_geocentric.pl?ID=AA&task=6&body=1&year=2016&month=2&day=1&hr=11&min=0&sec=0.0&intv_mag=1.0&intv_unit=1&reps=5 > 2016 Feb 01 11:00:00.0 19 14 15.421 - 20 38 03.89 > ************************ > http://ssd.jpl.nasa.gov/horizons.cgi#results > 2016-Feb-01 11:00 19 14 15.4172 -20 38 03.896 > *************** > http://vo.imcce.fr/webservices/miriade/?formsMercury2016-02-01T11:00:00.0019 14 15.42394 > -20 38 3.8918 Nobody is curious about the discrepancies between those positions? For example, the format of the USNO coordinates implies about 10 mas (milli arc second) accuracy. But compared to JPL HORIZONS, the difference is 54 mas. OK, that's not actually unreasonable. Maybe the USNO values carry an extra decimal place to ensure negligible loss of accuracy due to roundoff. I can go along with that. But what about HORIZONS vs. IMCCE? The coordinates differ by 95 mas. That's far more than a few counts in the last place! Maybe the time scale is not the same for all three sources? Mercury moves about 1.75 arc seconds per minute of time, so 95 mas is equivalent a time error of 3.2 seconds. UT1 is about .026 s ahead of UTC and 68 behind TT. Neither number is close to 3.2, so a time scale mistake doesn't look like a good explanation for the position discrepancy. No do I think we can blame differences between ephemerides. Here is the geocentric geometric place of Mercury at 2016 Feb 1 11:00:00 UTC from three major JPL ephemerides going as far back as 1997: 19h13m19.3193s -20°39'56.415 DE430 19h13m19.3193s -20°39'56.416 DE422 19h13m19.3193s -20°39'56.412 DE406 I think IMCCE has their own ephemeris, but could it differ from JPL by 95 mas? Of course that's insignificant for navigation. But when precise computations differ by that much, frequently there's a mistake somewhere. I know that from painful experience!
