search

skyfielders / python-skyfield

Elegant astronomy for Python
MIT License
1.43k stars 213 forks source link

apparent().altaz() #279

Closed scottbgoldblatt closed 5 years ago

scottbgoldblatt commented 5 years ago

The results of this do not agree with online calculators, and do not line up with imagery collected with a camera.

scottbgoldblatt commented 5 years ago

earth = planets['earth'] sighting = earth + Topos('39N', '76E') ts = load.timescale() t = ts.utc(2019, 3, 20,0,15,12) star = Star(ra_hours=(0,0,0),dec_degrees=(0,0, 0)) az,el,d=sighting.at(t).observe(star).apparent().altaz('standard') print(az.degrees,el.degrees)

brandon-rhodes commented 5 years ago

Your script prints out two numbers, but I am not sure in which direction you have found them in error. Please supply your camera imagery and the output of an online calculator that agrees with your camera imagery, so that I can determine how big the discrepancy is and what might be causing it. Thanks!

GammaSagittarii commented 5 years ago

I am not surprised that it is so. The thing is looking at the altaz code, altaz calculations are not precessed and therefore they can't match observed things. This can be "confirmed" by looking at the default settings on horizons: "Airless apparent azimuth and elevation of target center. Adjusted for light-time, the gravitational deflection of light, stellar aberration, precession and nutation. " @brandon-rhodes I really think 'epoch=date' should be default behavior for most functions(ecliptic_latlon especially) , since I think most of the time people want results that actually match reality. Somewhat connected issue https://github.com/skyfielders/python-skyfield/issues/273

brandon-rhodes commented 5 years ago

@GammaSagittarii I'm a bit confused by your claim. An epoch needs to be specified when asking for RA/dec coordinates because those coordinate systems shift through time. But the coordinate system for altaz is the horizon of a spot on the Earth at a given exact moment — which isn't affected by an epoch?

GammaSagittarii commented 5 years ago

@brandon-rhodes , you are correct.

In haste and in obviously not so clear state of mind, I had this hunch, so I just checked what are the defaults on horizons that I quoted - instead of properly checking everything, I went full retard, I am sorry.

Know that I taken a better look at this, if the reporter of the issue is not as clueless as I am, and there actually is an error, it could still be that my hunch is correct but for a slightly different reason.

Since he is creating custom star object using ra, dec, looking at skyfield docs - that coordinates for creation are not for epoch of date. But if you are looking at a star, and measure its ra, dec they are for epoch of date not for J2000 right?

So in effect he is actually creating objects with wrong data, and therefore getting wrong results. I hope at least this analysis of the problem is helpful, after my brilliant previous post.

So solution might be as simple as star = Star(ra_hours=(0,0,0),dec_degrees=(0,0, 0), epoch=t)

brandon-rhodes commented 5 years ago

Thanks for the clarification! :) Specifying the epoch might make a difference, but a very small one; would it be big enough to be easy to detect with astrophotography, though? I guess it depends on what kind of camera @scottbgoldblatt is guiding with the coordinates. I'll be interested to hear more information when he gets a chance!

GammaSagittarii commented 5 years ago

@brandon-rhodes I am humbled by your, patience, politeness, and the work you are doing. I am also interested in hearing more information.

brandon-rhodes commented 5 years ago

@scottbgoldblatt I am going to close this issue temporarily since, without numbers that don't match, I cannot proceed to investigate it. Once you have numbers and a link to the site that's giving them to you, though, please feel free to re-open and comment with further information. Thanks!