Calculating the Position and Orientation of the Moon

Umm... are you claiming that this vid was made in CANADA?

He is, and he's completely and laughably wrong.
Thread: Debunking the "Tilted Moon Filmed in Canada" Nonsense

Do you understand and accept that the moon has a north rotational pole which faces roughly in the same direction as Earth's north rotational pole- that is, toward Polaris?

I finally got around to trying out your spreadsheet with a photo of the Moon I took last year. It works great! (when you enter the data in the correct spot....lol)

photo of the Moon taken on 9/9/2012: [link to i439.photobucket.com]

The spreadsheet says the moon was 43.04% full and 60.11 degrees tilted from vertical: [link to i439.photobucket.com]

Used gimp to measure the angle and got 29.92 degrees from horizontal, which equals 60.08 degrees from vertical. Well within the margin of error. : [link to i439.photobucket.com]

Last Edited by BoxerLvr on 03/13/2013 12:30 AM

Awesome! I'm thrilled to see that it's working great for you!

This guy (the duck) is an ignoramus (proved by his nonsense claims) but you must review your assertion.

The Earth's north polar axis points about 23.5 degrees away from the north ecliptic pole. However, the Moon's north polar axis points within 1.5 degrees of the north ecliptic pole. Thus, the Moon's north celestial pole points to the north ecliptic pole. The north ecliptic pole is the point in the Earth's (or Moon's) sky that marks the northern perpendicular to the Earth's orbital plane: about 23.5 degrees away from the Earth's north celestial pole, in the constellation of Draco.

[link to en.wikipedia.org]

Yah, that helps.

Of course, it isn't the Moon's ROTATIONAL pole that is getting people in a tizzy. Few of them are that familiar with the Moon's features, as to be able to tell its orientation from them alone.

It is the orientation of the terminator, and that lies to the relationship between the plane of the Moon's orbit, and the plane of the ecliptic.

The Moon could easily be tilted 50 degrees in the plane of its own orbit, but the terminator would still show the same relationship to the Sun.



So, if my morning coffee has kicked in right, the surface features of the Moon should "wobble" by about 46 degrees over the course of a year. The position of the Moon in the sky should appear to shift North and South (and the path traced through the night sky) also in reference to that 23 degrees. But the orientation of the Moon, terminator and all, will depend on the latitude of the observer and the height in the sky.


On the other hand, I DID just wake up...

Semi-analytical: "(...) they are related to the JPL numerical integration DE 2000 through the involved constants."

M. Chapront-Touze and J. Chapront (1988). "ELP 2000-85: A semi-analytical lunar ephemeris adequate for historical times"
Astron. Astrophys. 190, 342-352: p. 350

Yes, technically it is semi-analytical because it does use some constants, but for the purposes of implementation in a spreadsheet it functions in an analytical manner - no fixed cutoff dates for when the solution is valid, you can extrapolate as far into the future or past as you like and it will yield a number even though the accuracy of that number will decrease over millenia.

While adding and testing new features to this spreadsheet I have discovered a bug; it will not yield accurate results if you set the current time for any date to 0hr 0min 0sec. For some reason it doesn't like that. It functions fine if you set it even just 1 second off from midnight, but it does not like midnight universal time. I had initially tested this sheet using real values and comparing to actual observations, but today I noticed the values "jump" at midnight UT if entered as 0 hours 0 minutes 0 seconds. The bug, whatever it is, only puts things off about a dozen arcseconds or so in RA and Dec (too small to matter for most purposes), but it's still annoying and it also affects the apparent az/alt values far more drastically. You can get around the bug by setting the time to the previous day at 23:59 universal time and setting the seconds to 60. That will yield correct values for midnight UT on the following day.

I'll try to track down the source of this bug later. If I can't figure it out by the time the new features are completed I'll implement a function in the new version to automatically set the time to 23:59:60 if 0:0:0 is entered.