Tag Info

Let me first name your maps correctly (you switched night and day maps): night= Import["http://eoimages.gsfc.nasa.gov/images/imagerecords/55000/55167/earth_lights_lrg.jpg"]; day= Import["http://eoimages.gsfc.nasa.gov/images/imagerecords/57000/57752/land_shallow_topo_2048.tif"]; The images have different sizes: ImageDimensions[day] (* ==> {2048, 1024} ...

I'm not sure what your goal is, exactly, but here is a simulation I cooked up. It should give you some ideas: metersToAU[m_] := m/(1.496*10^11) ; orbit = First@AstronomicalData["Earth", "OrbitPath"]; earthCurrentPosition = AstronomicalData["Earth", "Position"] // metersToAU; radiusEarth = AstronomicalData["Earth", "Radius"] // metersToAU; radiusSun = ...

Yes, the basic idea is here: Demonstration: Day and Night World Clock Now, to use the images, create an alpha channel using the computed the day-night curve--called "terminator" curve (rasterize it in grayscale), and compose two images using ImageCompose with the generated alpha channels (SetAlphaChannel to the second image). Try the following code: a = ...

It took me quite a while, but finally, here's a visualization of the perigee of Flamsteed's comet: I should first note two things: first, some of the needed data for computing the orbit of comet C/1683 O1 was missing in AstronomicalData["CometC1683O1", "Properties"], and I had to pull information from external sources to supplement the information ...

Jean Meeus's Astronomical Algorithms (as well as the related book Astronomical Formulæ for Calculators) is what you should start looking at whenever you need to deal with algorithms for quantities of astronomical interest. For instance, here is a translation of Meeus's method for the Julian Date: Options[jd] = {"Calendar" -> "Gregorian"}; ...

A couple of years ago I was in an email conversation about this topic with Jeff Bryant, a WRI employee. He was not directly responsible for AstronomicalData, but he told me that Mathematica did not correct for atmospheric refraction. Good to know, as the refraction at the horizon is about the same size as the sun itself (both in degrees). At that time I ...

This is not a full answer, but more a response to J.M.'s comment and provides a routine to calculate $\Delta T$ which was sitting on my hard disk. This is intended as a starting point for further calculations. deltaT::usage = "deltaT[date] calculate the arithmetic difference, in seconds, \ between the Terrestrial Dynamical Time (TD) and the Universal \ ...

Search for brfASTRO.m which is a fantastic astronomy package that Peter Breitfeld wrote. He offers wonderful material on his homepage. I used many of his routines (thank you Peter!) Here is my (long but untested) version which I probably also copied partly and forgot from where. Please contact me if you feel that proper credit is due! This is a small part ...

A bit of spelunking reveals that AstronomicalData delegates the calculation of those properties to the function PlanetaryAstronomy`Private`RiseSetsX. You can verify this by evaluating: On[PlanetaryAstronomy`Private`RiseSetsX] AstronomicalData["Moon", "NextRiseTime"] Off[PlanetaryAstronomy`Private`RiseSetsX] My impression is that it is performing a purely ...

Oh, I was going to say the same thing. Here's a picture instead of me clicking in the little screw icon... This pastes the query into your document (and runs it too): WolframAlpha["Sunrise june 25, 2013", {{"DaylightInformation", 1}, "ComputableData"}] Then I assigned the results to a symbol for further processing.

WolframAlpha["Sunrise june 25, 2013", {{"DaylightInformation", 1}, "ComputableData"}, PodStates -> {"DaylightInformation__More"}] gives {{"begin astronomical twilight", "3:56 am PDT"}, {"begin nautical twilight", "4:40 am PDT"}, {"begin civil twilight", "5:18 am PDT"}, {"sunrise", "5:49 am PDT"}, {"sunset", "8:33 pm PDT"}, {"end ...

Regarding your first point: The planetary orbital planes are indeed inclined to that of the Earth and you have the inclinations. However, you also need to know the azimuthal locations of the ascending and descending nodes which together define the line about which to pivot the orbital ellipse. Regarding your second point: If you assume, as you say, that ...

Leap seconds are added by international agreement so that UTC time functions keep the earth at the same point in its orbit about the sun by calendar time during the year. The AstronomicalData function appears not to be terribly well documented. Here is an answer I got from "Premier Support," which is not terribly helpful: Questions and comments: I need ...

The U.S. Naval Observatory keeps a list of when leap seconds have been added and I think it has been at a stable URL for a while: http://maia.usno.navy.mil/ser7/tai-utc.dat You could use this if you need to know when seconds were added. I wrote a solar position routine, and used this for a while, but I changed it to use an output file from their MICA ...

Once can see by using Trace that an apparently simple call is far more complex than you might imagine. Why it is designed this way, and if it needs to be, is an entirely different matter. Be prepared to forcefully terminate Mathematica (or at least Quit[] the kernel) and then run: AstronomicalData["Mercury", {"RightAscension", {2012, 10, 11, 12, 13, ...

One way to overcome this issue is simply to define functions to store the data, so that it AstronomicalData is only needed once for each value, using something like astroData[datum_, object_, dayoffset_, location_] := (astroData[datum, object, dayoffset, location] = AstronomicalData[object, {datum, DatePlus[Date[], dayoffset], location}]) Then the ...