New utility by Jeff Conrad: Sun/Moon calculator

[QT Luong]

A new utility by Jeff Conrad has been posted:
Sun/Moon Calculator (http://largeformatphotography.info/sunmooncalc/).
Here the description by Jeff:

I have updated the Sun calculator so that it now gives rise and set
times and positions for the Moon as well as the Sun.

With the default settings, the calculator (/sunmooncalc/)
will provide the basic information that photographers usually need:
<ol>
<li> A table of Sun and Moon rise and set times and azimuths
<li> A table of Sun and Moon positions throughout the day
</ol>

I've also added a few other features:
<ol>
<li> The ability to specify nonzero altitudes for rise and set--handy
if the visible horizon isn't level. For example, Mt. Whitney has an
altitude of approximately 10 degrees from most spots near Movie Rd;
typically, the Moon hits Mt. Whitney about an hour before and 10
degrees to the south of "official" moonset.

<li> The ability to search for dates on which Sun or Moon rise or set
meet certain criteria, such as rising or setting within a certain
azimuth range, or the Moon rising or setting with a certain phase, or
within a certain time of Sun rise or set. These can be combined with
nonzero rise and set altitudes; for example, you could find the dates
on which the Moon sets near Mt. Whitney with alpenglow on the
peak. You also easily could show that Dennis diCicco determined the
correct date (1 November 1941) for Moonrise, Hernandez, New Mexico.
</ol>
At first glance, the Rise/Set Options may seem a bit complicated,
especially when reading the Help section, but they actually are fairly
simple to use after a few tries.



Other Changes

The location database has been expanded so that it now covers 380+
locations, including most national parks in the United States and
Canada.

The handling of daylight saving time/summer time is more robust,
although the start and end times still are tied to U.S. rules (in the
southern hemisphere, these times are simply reversed). I've added most
of the common fractional-hour time zones.

Performance

Performance is fine when calculating rise/set times over the course of
a few weeks, but the program is slow when doing searches extending
over several years--such is the consequence of implementing
astronomical calculations in a script. A year's worth of rise/set
times takes just over 7 seconds on my 1.4 GHz Pentium 4. A 10-year
search of dates takes just under 60 seconds, and prompts a "slow
script" warning from Internet Explorer and Firefox unless the default
warning triggers have been changed. Nonetheless, it's faster (as well
as much easier) than grabbing the data from the USNO site and
rearranging and analyzing it.





Please feel free to leave any questions and comments here.

[Giacomo GIRINO]

great, great, great! So many times I've just been guessing at what time the moon would rise and in what direction etc. etc.
I always went on guessing based only on my experience but that works for the places I know well only and not too precisely either. I many times thought I should have worked out something like this calculator but I was just too lazy to.
Thanks Mr Conrad!

Lino (45°8'N, 8°31'E)

[John_4185]

great, great, great! So many times I've just been guessing at what time the moon would rise and in what direction etc. etc.

Pity. There are published tables.

[Doug Dolde]

"Pity. There are published tables." WTF is that supposed to mean? You must be a Pommie with a stick up his behind.

I think this is the best sun/moon calculator I have seen. Thanks.

[Paddy Quinn]

Jeesh - you sound like some kind of Aussie - keep the convict talk to yourself. As far as I know jj is all Yank?

BTW - there are other excellent online calculators of this sort online

[Ralph Barker]

Excellent addition to the site, QT, and nice job, Jeff.

Now, if we could just get one of these to interact with topo maps, and overlay the shadows in 3-D, we'd be all set. (lol)

[Jeff Conrad]

Don't laugh too hard, Ralph. In most cases, I wouldn't know what to do
with a Moon azimuth without a computerized topo map (though I wish they'd
give altitudes as well). I think the 3-D features of most such maps have a
way to go, but they still sometimes are helpful.

Several astronomy programs will simulate the passage of a celestial body
across the horizon, and allow this to overlay a photograph. The rub is
that you need a photograph of every view from every location that you want
to model. I use a program that generates a table of Sun and Moon positions
vs. landscape features; it's a bit short of VR, but the next step would not
be out of the question for someone good at graphics. Were there sufficient
demand, we might already be there.

[John_4185]

Now, if we could just get one of these to interact with topo maps, and overlay the shadows in 3-D, we'd be all set. (lol)

earth.google.com/ (http://earth.google.com/)
It interacts with GPS.

[chris_4622]

I've used this for sunrise information: http://www.hourworld.com/

chris

[Jeff Conrad]

If you need only information for the Sun, Wide Screen Software (http://www.wide-screen.com)'s SunPATH ($99)
looks as if it's very nicely done. It's available for the Mac, and using a
Mac emulator, for Wintel machines. John Cook posted

this link (http://store.yahoo.com/cinemasupplies/sunsoffowwin.html) that has SunPATH on sale for $87 during September.

There are several native programs available for Wintel machines, such as
Fossil Creek's Heavenly
Opportunity (http://weba.viawest.net/users/fcs/ho/) ($25) or Digital Light &
Color (http://www.dl-c.com)'s Ephemeris. Neither has all the features of the Sun/Moon
Calculator that I wrote, but they're much faster, and Heavenly Opportunity
has a much larger location database. Ephemeris is free, so the
cost/benefit ratio is hard to beat. Heavenly Opportunity allows searches
similar to those of my Sun/Moon Calculator, so it may be worthwhile for
those who do many searches in attempt to find the perfect photo op.
Neither program allows nonzero rise/set altitudes.

[Spencer Cliss]

Another tool I believe not yet mentioned is Sun Clock. It's free and has worked well for me.

http://www.mapmaker.com/sunclock.htm

[Giacomo GIRINO]

Ralph Barker wrote:
>... if we could just get one of these to interact with topo maps ...

what I've done is use an image of a map as background for an Excel graph then from the data from Conrad's calculator, overlay lines in the right direction (e.g. direction of sunset). It can be automated with excels functions:
- with the sun/moon calculator create a table with resulting data spanning a priod of interest (first thought: 1 year!!)
- import the table in excel
- create a function that searces the table for a date you type and retrieves relevant data
- work through the necessary sines, cosines and tangents an have excel plot lines in the wanted directions over the map

not 3D but I hope it will help me choose the right spot where to get moon reflections on the Po river.

Lino 45°8'N, 8°31'E

[Jeffrey Sipress]

Thanks, but on-line calculators are good only before you leave the house. When you need it most, you're on the road, or in the middle of a beautiful nowhere. What good is a laptop with a browser then? A stand alone app is what's really needed.

[QT Luong]

Jeffrey, maybe I am wrong, but I think that Jeff wouldn't mind if you copied the four files that make up the Sun/Moon calculator to your laptop for personal use. If you do so the calculator will run as a stand-alone.

[Jeff Conrad]

Jeffrey, maybe I am wrong, but I think that Jeff wouldn't mind if you
copied the four files that make up the Sun/Moon calculator to your laptop
for personal use.


Not a problem. If you have a Wintel machine, though, you also might want
to consider the other two programs that I mentioned--they'll run a lot
faster. Since Ephemeris is free, why not? And Heavenly Opportunity might
be worth it just for the database.

I don't mean to suggest that other similar programs aren't good. However,
like my calculator, Ephemeris and Heavenly Opportunity were written by
photographers primarily for photographers, so they provide azimuths as well
as rise and set times. Many other almanac programs don't do this.

If you have a Mac, I don't know what to recommend, although that certainly
doesn't mean that nothing is available--it's just that finding it hasn't
been my top priority.

[Leland]

Great calculator. I've been looking for an app like this for calculating the lunar times. You mentioned that you don't mind if we copied the 4 files to our laptops, where can I get those 4 files?

If not the files can I get the formulas used? I could easily write a program using VB to have a stand alone executable but I don't want to have to figure out the formulas used in the calculations.

Thanks,
Leland

[QT Luong]

lfphoto.info/sunmooncalc/index.html

lfphoto.info/sunmooncalc/SunMoonCalc.js

lfphoto.info/sunmooncalc/SunMoonCalcHelp.htm

lfphoto.info/sunmooncalc/SunMoonCalcOptions.htm

[Gordon McKinney]

Really nice.... I've added a link to your site from my Photographic Cheat Sheet....

http://www.night-ray.com/photo-cheat.php

[sunposition]

SunPosition at http://www.sunposition.net is a really handy online application for photograpers.
See this post:

http://www.largeformatphotography.info/forum/showthread.php?t=18736

[sunposition]

Just to let you know:

SunPosition has now just over 48,400 preset locations for members.

http://sunposition.net

[chris_4622]

I use HourWorld. They have a demo model you can try.

[Steve Kefford]

I use Ephemeris by J Sachs. It runs on a PDA, so I can take it out in the field with me. Cost £0.00.

Steve

[Graeme Hird]

I use SunMoonCalc. It also costs nothing and encourages our forum members to share their excellent work.

Graeme

[Ted Harris]

Good work Jeff. If you just want a quick and dirty look that also gives you times for civil twilight, etc. then take a look at:

http://aa.usno.navy.mil/data/docs/RS_OneDay.html


You will get a page like this when you plug in the location by by name:

U.S. Naval Observatory
Astronomical Applications Department


Sun and Moon Data for One Day

The following information is provided for Orford, Grafton County, New Hampshire (longitude W72.1, latitude N43.9):

Friday
5 January 2007 Eastern Standard Time

SUN
Begin civil twilight 6:50 a.m.
Sunrise 7:23 a.m.
Sun transit 11:54 a.m.
Sunset 4:25 p.m.
End civil twilight 4:58 p.m.

MOON
Moonrise 5:28 p.m. on preceding day
Moon transit 1:23 a.m.
Moonset 9:05 a.m.
Moonrise 6:39 p.m.
Moonset 9:30 a.m. on following day


Phase of the Moon on 5 January: waning gibbous with 95&#37; of the Moon's visible disk illuminated.

Full Moon on 3 January 2007 at 8:58 a.m. Eastern Standard Time.

[vinny]

[QUOTE=Jeff Conrad;125196]If you need only information for the Sun, Wide Screen Software (http://www.wide-screen.com)'s SunPATH ($99)
looks as if it's very nicely done. It's available for the Mac, and using a
Mac emulator, for Wintel machines. John Cook posted

this link (http://store.yahoo.com/cinemasupplies/sunsoffowwin.html) that has SunPATH on sale for $87 during September.

SunPath is a very useful program that's easy to use. It gives you all the info you need on one page along with shadow factors if you need that sort of thing. You can figure out how long an objects shadow will be at any given time. The suunto tandem inclinometer and sunpath make for easy foolproof calculations.

vinny

[Eric James]

This is an awesome tool - thank you very much Jeff Conrad.

To those of you who haven't discovered this LF.INFO utility, it's worth checking out. Enter your destination, your trip dates, and print - laminate in a Ziplock bag and you're good to go.

http://www.largeformatphotography.info/sunmooncalc/

[QT Luong]

Jeff Conrad has upgraded the Sun/Moon Calculator (http://www.largeformatphotography.info/sunmooncalc/) to version 3.5. Here is a description of changes:

1. It is now possible to specify a range of rise/set altitudes. This is
much easier than manually adjusting the azimuth range and time
difference to simulate an altitude range when the objective is to find
the days when the Sun or Moon pass through a "window" of azimuth and
altitude.

2. There is an option to search the location database for locations
matching a pattern. In some cases, this is faster than selecting a
location from the list; for example, cycling through all locations in
California. There is an option in user preferences to allow Perl-style
regular expressions in search patterns.

I'm still trying to decide if the search option should be enabled by
default; the user can enable or disable it via the preferences form.

3. There is now some support for browsers that provide tabbed viewing.
For the most part, the user can specify whether new windows open in new
windows or in tabs; behavior is also dependent on browser settings.

4. The user interface has been slightly revised in response to a couple of
user comments. I've added borders around the input areas to make it
more obvious what they do; I've also changed the background to light
gray (the same color as the Sun columns in the output of the current
version) so that the input areas are more obvious. There is an option
to have inactive areas of the main form "grayed out"; this makes more
obvious which of two mutually exclusive options has been selected.

The "graying out" also works better with the gray background. The gray
isn't very dark, but I think I can make the "graying out" work with a
white background if this is a problem

5. I've (finally) updated DST rules for several countries; the ones most
important to the LF users probably are Canada and Australia.

6. Form validation has been revised to avoid problems that result from the
focus() bug in Firefox. In previous releases, entering the wrong value
could result in an endless loop. Because of the change, error handling
with Firefox is slightly different from that with Internet Explorer.

Client sniffing is always a guess; many browsers spoof some of the
navigator properties, so it's possible that some other browser will be
misidentified as Firefox. The validation still works, but it's not
quite as nice as with IE.


I've tested with IE 7, Firefox 2, and Opera 9.21. I've also tested briefly
with the Safari Beta for Windows, but it's still too buggy for a thorough
evaluation.

[OldBikerPete]

Great calculator.
However, I think you need to correct azimuth calculations for the southern hemisphere. Sunrise and sunset positions for Melbourne, Australia calculate to 120° and 240° which puts the sun south of Melbourne. I expect this should be 60° and 300° respectively.

[Jeff Conrad]

Are you talking about today? If so, the rise and set azimuths for Melbourne are as they should be--you folks are in the middle of summer. The situation in the southern hemisphere is the reverse of what it is in sunny (er, rainy) San Francisco; the Sun still appears to move from east to west, but its azimuth decreases during the day, transiting to the north, and further decreasing until it sets. In the summer, rise and set are south of east and west, consistent with a longer day; in the winter, rise and set are north of east and west, with values essentially as you suggest. This is what happens, isn't it?

Other calculators, including the U.S. Naval Observatory Data Services (http://aa.usno.navy.mil/data/) Sun and Moon positions page (http://aa.usno.navy.mil/data/docs/AltAz.php) give essentially the same values as the LF calculator.

[Ole Tjugen]

Eh - since 0 degrees is due north, and the sun at local noon in the southern hemisphere is due north, the azimuth should decrease from dawn to noon, then jump from 0 to 360, and decrease again.

60 and 300 degrees is consistent with high southern latitude winter, in the summer the arc is more than 180 degrees.

So the calculator is essentially correct.

The only problem I've found is north of the polar circle - if there is no sunrise or sunset, it doesn't display the azimuths. Maybe it could default to 00:00 to 24:00 in those cases?

[Jeff Conrad]

That's certainly an interesting idea, but it may prove a bit messy to give a reasonable implementation. In the default case, i.e., within the polar circles on days on which the Sun or Moon doesn't rise or set, it might be fairly straightforward. But in more special cases, e.g., at moderate latitudes on a day on which the Moon doesn't rise or set (there's one of each every month), results could be a bit confusing, especially if the user has specified something like 1-minute intervals for +/- 10 minutes on either side of the phenomenon that did not occur. Sun "rise" or "set" also may not occur at moderate latitudes if a nonzero altitude has been specified for rise or set; the greater the altitude, the further outside the polar circles this can happen.

At the very least, the suggestion to manually select 0:00 and 24:00 for the display of Sun and Moon positions when rise or set do not occur should probably be added to the Help page. You obviously figured out the solution, but it may not be obvious to everyone.

I recently found a couple of real bugs, though they won't affect most users:

The latitude of Shanghai is wrong (it should be 31:14 rather than 39:14).
Handling of an observer at a height greater than the surrounding terrain isn't always correct. If a nonzero Observer's Height and a nonzero rise/set altitude are both specified, the altitude is still adjusted for the observer's height--this should not happen. Furthermore, atmospheric refraction isn't included until the apparent altitude reaches zero. If an observer is substantially above the surrounding terrain, the Sun or Moon is visible at apparent altitudes less than zero, and the effect of refraction should be included. In most cases, this isn't an issue, but an observer watching the sunrise from Pikes Peak in Colorado can see the Sun at an apparent altitude of about -1.8 degrees.

These problems will be fixed in a future version. In the meantime, there are simple workarounds for two of the issues:

If the location is Shanghai, select it, then click Copy Place, select Custom Location, and edit the latitude.
For an elevated observer, either ensure that a nonzero rise/set altitude is not also specified, or if a nonzero rise is required, set Observer's Height to zero. Again, this is a pretty unusual situation.

[OldBikerPete]

Are you talking about today? If so, the rise and set azimuths for Melbourne are as they should be--you folks are in the middle of summer. The situation in the southern hemisphere is the reverse of what it is in sunny (er, rainy) San Francisco; the Sun still appears to move from east to west, but its azimuth decreases during the day, transiting to the north, and further decreasing until it sets. In the summer, rise and set are south of east and west, consistent with a longer day; in the winter, rise and set are north of east and west, with values essentially as you suggest. This is what happens, isn't it?

Other calculators, including the U.S. Naval Observatory Data Services (http://aa.usno.navy.mil/data/) Sun and Moon positions page (http://aa.usno.navy.mil/data/docs/AltAz.php) give essentially the same values as the LF calculator.

Stop spouting and think for a minute. Melbourne is at 34° South latitude. There is NO time of the year at which the sun rises or sets south of East or West.

[Ole Tjugen]

Think for a minute:

I'm at the opposite situation, far north.

At midwinter, the sun rises (barely) in the south-southeast, and sets (almost immediately) in the south-southwest.

At the equinoxes, it rises in the east and sets 12 hous later in the west.

In the summer it rises in the north-northeast, and sets 22 hours later in the north-northwest. A little farther north than here it doesn't set at all, but circles around through due north.

So in summer in the northern hemisphere it rises and sets north of due east/west.

In the southern hemisphere it's just the same (only opposite) - in the summer it rises and sets south of due east/west.

The calculator is correct.

[Jeff Conrad]

To an observer in space, the apparent motions of the Sun and Moon are quite simple. Governed primarily by Earth's rotation, the paths of the Sun and Moon are quite simple: parallels determined by the Sun's or Moon's declination (angle with the plane of the celestial and Earth's equator). To an observer at a particular point on Earth, the apparent paths are a bit more complicated.

The attached file illustrates what's happening. The figures are for the northern hemisphere; the situation in the south is just the reverse, as Ole described (imagine everything mirrored about the vertical line through the zenith). The purple axis through P is the north-south axis of the celestial sphere, as well as the axis of Earth's rotation. The paths of the Sun and Moon are circles, as shown in yellow.

To an earthbound observer, whose horizon is the plane NESW, the paths appear anything but circular, which is why an azimuth/altitude table seems so complex.

The figures indicate the general characteristics of the Sun's path, for any geographic latitude. Ar and As are the azimuths of rise and set. The descriptions that follow are for the northern hemisphere.


Summer solstice: The Sun rises and sets north of east and west, and reaches its greatest maximum altitude at due south.
Spring/Fall equinoxes: The sun rises and sets due east and west; day length is approximately 12 hours, for all latitudes.
Winter solstice: The Sun rises and sets south of east and west, and reaches its least maximum altitude at due south.

[Khosrownia]

Great program, Jeff - thank you.

Farzad

[Yincognyto]

Jeff, I'm trying to use your utility to display information about sun/moon rise, sun/moon culm, sun/moon set in a weather "skin" that I wrote for a free software called Rainmeter. I'm trying to use your utility because it gives both sun and moon data in one single table, instead of having to access two times the US Naval Observatory site, which can sometimes be tricky (possibly because it's "busy" processing worldwide requests?).

The thing is, I have a problem... The Rainmeter program that's displaying my "skin" is using a plugin called WebParser, which is essentially parsing the webpage information, making the grabbing of individual elements from the webpage possible through RegEx (regular expression processing). But this plugin requires that I use URL parameters to grab the information needed, so I use something like

http://www.largeformatphotography.info/sunmooncalc/?latlon=Nxx:xx:xx,Exx:xx:xx&tz=3&dst=n&dates=6/20/2015,+4d,1d&calc=display

to do the job. The problem is that when executing this, the browser -Firefox 37.0- (and most likely the WebParser plugin itself) will open up two webpages : one with which looks exactly like http://www.largeformatphotography.info/sunmooncalc/ with the text boxes filled and another one, which is actually the page I need - the equivalent of pushing the "Display" button from the first page. Now this is unlike any other site that I tried and it makes parsing the information needed impossible, as the plugin grabs - quite logically - only the first webpage (the one which doesn't display the results, only the filled form).

So, the bottom line is that I want to use your utility, but I can't. Can't you make the Sun/Moon Calculator URL Parameter method only display the results page, so that my skin would be able to grab the correct information? Plus, I've also noticed another undesirable behaviour : when having multiple tabs open with your forms/tables, pushing the "Display" button in one tab would generate no effect in that page (or wouldn't open a new tab with the desired table), but it will display what I need in an "already used" tab, replacing the previous table there. I'm sure this is not the expected behaviour...

Thank you for your utility and great job, by the way! If only those 2 issues above could be corrected...

[RSalles]

Hi Yincognito,

Even not knowing your application at deeper level, it's obvious that the app is parsing the special character "?" as a break or other command. Can you type the hole string in quotes or commas to test if what's enclosed in is correctly parsed?

Renato - who has spent many years trying to nail regex expressions at the shell unix terminal, sometimes without much success,

[Yincognyto]

First of all, thank you for your answer, Renato.
It's not a "?" problem, I'm 100% sure of it. In fact, I didn't yet write the RegEx string, as it wasn't necessary. Rainmeter (the actual application that my "skin" is built upon) has a little tool to check whether the RegEx string correctly parses the info from a webpage. It's quite intuitive, simple and effective. You can download it here (http://rainmeter.net/RainRegExp.zip) and check for yourself. I don't know if it works without the main application (Rainmeter), but it should.

Anyway, you'll see that after pasting the sunmooncalc link in the "Enter web site URL or browse for HTML / text file" textbox from RainRegExp utility and hit "Connect", you'll get in the big textbox below the page source of the actual form webpage and not the results (table) webpage. You can further check if it's really true by chosing to view "Page Source" in your browser. The data from the form webpage is the same as the one that RainRegExp (and implicitly the WebParser plugin from Rainmeter) is receiving. I think this has to do with the fact that the results webpage is opened up as a "popup". But basically, the thing is...the "first" webpage (the one with the form) shouldn't be opened in the first place, only the results page.

As for the "?" character, since working at my skin for Rainmeter I've become quite fond of RegEx and I dare to say, quite good at it :) I'm not a rookie anymore in this and there's no way I could incorrectly write a "?" without escaping it. Plus, one very important aspect of the Rainmeter WebParser syntax is that the URL of the site is separated from the RegEx string (e.g. they belong to different lines of code or "options" as they are called in Rainmeter).

A simple example of Rainmeter code:

[NASASunTimes]
Measure=Plugin
Plugin=WebParser
Url="http://aa.usno.navy.mil/cgi-bin/aa_mrst2.pl?form=2&ID=AA&year=2015&month=5&day=10&reps=5&body=10&place=&lon_sign=1&lon_deg=26&lon_min=23&lon_sec=59&lat_sign=1&lat_deg=70&lat_min=57&lat_sec=35&height=&tz=3&tz_sign=1"
RegExp="(?siU).*<pre>.*\n(\d.*)\n(\d.*)\n(\d.*)\n(\d.*)\n(\d.*)\n.*</pre>.*"
UpdateRate=3600

As you can see, the Url and RegExp strings are different things, so a "?" in the URL can't affect or be incorrectly interpreted by the RegEx, which takes an entirely different string as a parameter. You can test this in the RainRegExp utility too - just paste the Url string rom the code below into the "Html to Parse" textbox and the RegExp string into the "Your RegExp" textbox (but do not include the quotes). You'll see the webpage is parsed correctly, resulting in 5 strings, each one describing its own date.

The issue is...I'm not even close to making a RegEx for Jeff's utility, as that would attemp to parse the form webpage, and not the results (table) one.

[Jeff Conrad]

Yincognyto,

I see what you mean. To be honest, the URL parameter interface was an add on, done late late in the process at the request of one user. The implementation strove to minimize the changes to the code. One consequence of this is that indeed two pages are returned. This was by design; the user who asked for the URL parameter interface wanted to use the Rise/Set Criteria feature to find dates on which the Sun or Moon position aligned with a terrestrial feature. The Az/Alt limits were set from a tool similar to the Sun/Moon Calculator Az/Alt Tool, and essentially derived from tolerances on the azimuth and altitude to the feature as determined by geodetic calculations. For someone who always wants a “bulls-eye” alignment, this works just fine. But for many—including me—other aesthetic considerations often come into play. Accordingly, I thought it useful to bring up the main form so that a user could open the Rise/Set Criteria form to make adjustments to the formulaic limits if necessary.

Thinking about it, it does seem that a URL query usually returns only the results (as with the USNO). But the URL parameter interface has been available for three years now, and I’m reluctant to make changes that could break apps that depend on the current behavior. Perhaps I can simply add a parameter to suppress display of the main form—but I need to see just how much work is entailed. Long ago, the output overwrote the main form—but in doing so created some problems, the exact nature of which I cannot recall.

Arguably off topic, but perhaps nonetheless relevant: if you have anything that runs iOS 3.0, you should take a look at Stephen Trainor’s The Photographer’s Ephemeris (http://photoephemeris.com). It’s a graphically oriented app that now implements much of what the Sun/Moon Calculator does, including date searches. And the implementation of elevation profiles is by far the most innovative that I have seen.

One thing TPE does not provide is tabular display of Rise/Set times and Sun and Moon positions, which you seem to be seeking and which I still sometimes prefer—but I may just be getting long in the tooth.

Sorry for the delay in responding. It’s been a long time since the last post to this thread, and I apparently got unsubscribed when the forum software was changed a while back

[Yincognyto]

Thank you for your reply, Jeff. I also agree that a new parameter for displaying only the results page is the best choice, that is if you decide it's easy/not time consuming enough and it doesn't break the already existing behaviour.

I already looked over Stephen Trainor’s The Photographer’s Ephemeris (and most of the other sun/moon rise/set+twilight sites over the internet) and you're right, I absolutely need a site that uses parameters and not exclusively Javascript - not necessarily a tabular results page, but a page accesible by using GET parameters. The WebParser plugin cannot manipulate Javascript code by itself, it simply parses the webpage source (and in the case of Javascript only sites, that consists of only the JS functions, not the actual result).

What I'm actually doing in my Rainmeter "skin" is:
- get the weather from a weather.com (http://wxdata.weather.com/wxdata/weather/local/FIXX5548?cc=*&unit=m&dayf=5) web query
- use the <lat>, <long>, <zone> and <dayf>/<lsup> sections from the above resulting xml to pass parameters to another site which will get sun/moon rise/set/culmination for the 5 days forecasted interval
- use the <lat>, <long>, <zone> and <cc>/<lsup> sections from the above resulting xml to pass parameters to another site which will get sun/moon rise/set/culmination/twilights for the current conditon day

For the last action, I need all 3 twilight types : begin/end astronomical twilight, begin/end nautical twilight and begin/end civil twilight in my skin, as I wrote a quite interesting algorithm for lightning up the sky .png image in my skin to simulate the exact appearance of the sky (and obviously the weather "icon") at every moment of the day. I do that by applying an alpha brightness to the default sky image, so all 3 twilight types are essential, because the sky will get from "night light" to lighten up very slow during the astronomical to nautical twilight, then lighten up using a similar rate during the nautical to civil twilight and then using an extremely fast rate to lighten up during the civil twilight to sunrise. After that, the sky will continue to lighten up slowly until midday, before performing the reversed order process for the second part of the day.

So you see, I'm trying to do an ambitious thing here, lol, but I need a site which will provide me with the required data, for the required interval, while using parameters. That's a lot of conditions to be met, but the result will be equally beautiful. Add that to using a very realistic sun .png image and NASA moon processed .png images for the respective age of the moon in days and you'll get the exact representation of what's outside (weather, sun, sky, moon appearance) for any given moment (I only need the "now" aka current condition moment and the day/night moments for the 5 days forecasted).

Oh, and I almost forgot...I'm trying all the above while having to access as few webpages as possible. Three would be ideal : one for the weather, one for the current condition sun/moon data and one for the forecasted days sun/moon data.

For example, I found this (http://www.sunrisesunset.com/custom.asp) which will almost provide me with what I need, but it has some inconvenients : the result page is a little difficult to parse, as the lines and the table itself are very "dynamic", plus I'm stuck with the data for a whole month while I need only 1 day + 5days data only. The latter would also force me to query that site more than once, if the starting date of the forecasted days is at the end of the month, as I would need to get the next month data as well, for the remainder days...

So you see, Jeff, I'm in a big dilema :D

[Jeff Conrad]

I don’t provide times for nautical or astronomical twilight, because they’re usually not relevant to terrestrial photography—at the end of evening civil twilight, it’s mighty dark. There are perhaps a few exceptions, such as very thin crescent moons and astrophotography, but I tried to show what’s needed most of the time while minimizing the clutter.

I’ve had many—mainly individual—requests for all manner of things; had they all been incorporated, it would be almost impossible to find the stuff that most people want. And the results wouldn’t fit on the page. Showing all twilight times is certainly one of the more reasonable requests. These times are easy to calculate, and I suppose it wouldn’t be that difficult to control using yet another user preference, but there already so many of those that I’ve gotten a few complaints ... In any event, it’s not currently high on the list. I’ve put most of the effort into the search features, because quite honestly, applications that just give Sun and Moon times are a dime a dozen. I do agree that with many sites (such as the USNO), you need to make a handful of calls to get all the data you need. I’ve never tried to do this with the USNO using GETs, so I can’t offer much comment.

For what you’re trying to do, TPE obviously isn’t the solution. And at least for now, the Web app is far behind the iOS app in capability. I also agree that sunrisesunset.com probably isn’t the ideal solution. Have you tried the API for timeanddate.com? Of course, I don’t know what they hit you for once the trial period expires.

It’s interesting that you’re calculating sky luminance, which can be a big issue when trying to catch the Moon without resorting to a composite exposure. I’ve long tried to do it using the CIE method (ISO 15469) but have had trouble finding a way to calculate zenith luminance at solar altitudes less than zero. How do you handle this?

Anyway, let me see what I can do.

[Yincognyto]

I undestand your point, Jeff. I didn't tried TimeAndDate API. I'm building my Rainmeter "skin" so that I could share this once it's finished (aka publish it on a site like DeviantArt or Customize.org). Using TimeAndDate API could be enough if it was only me that we're talking about (and even then, I don't know if they allow parameters or they still do it exclusively by Javascript, like they do for the main site), but I envision a "skin" that could be potentially used by other Rainmeter users, as well.


It’s interesting that you’re calculating sky luminance, which can be a big issue when trying to catch the Moon without resorting to a composite exposure. I’ve long tried to do it using the CIE method (ISO 15469) but have had trouble finding a way to calculate zenith luminance at solar altitudes less than zero. How do you handle this?

Oh no, I'm not using that type of calculations - I'm not that much of an expert. I thought about it though, got some info about it and stuff, but decided it was best (and enough) to keep it very simple. My method is quite straightforward...although it may seem complicated after reading below :P...

1) I set a "day begin" time variable (which used to be 00:00 in 24h time, but it logically should be = sun transit time - 12 hours, OR, if sun transit time isn't available, = the middle night time point between astronomical twilights/nautical twilights/civil twilights/sunrise-sunset). This is essentially the absolute middle of the night. For example, if sun transit time is 13:10, then the "day begin" would be 01:10. If sun transit time isn't available (at high latitudes in certain months, for example), but I have let's say the astronomical twilights of 02:34 and 22:40, then the "day begin" would be the middle night point between them, which is 00:37.

2) I set a "day end" time variable (which used to be 24:00 in 24h time, but it logically should be = sun transit time + 12 hours, OR, if sun transit time isn't available, = the middle night time point between the next astronomical twilights/nautical twilights/civil twilights/sunrise-sunset). This is essentially the absolute middle of the next night. The calculation is similar to the "day begin" variable, except it's 24 h later.

3) Now I have all the points in time during a 24h day when the sky brightness rates are changing (aka when the sky brightness is changing slower or faster): "day begin", morning astronomical twilight, morning nautical twilight, morning civil twilight, sunrise, sun transit, sunset, evening civil twilight, evening nautical twilight, evening astronomical twilight and "day end".

4) I then assign predetermined values of "brightness" to each one of the above events ("tint points" like I use in my skin - see section "ImageTint" here (http://docs.rainmeter.net/manual-beta/meters/general-options/image-options) to understand how brightness is simulated by "tinting" an image). By trial and error I noticed the following are decent aproximates, at least for my latitude and season (the values vary between 0 and 255, obviously, as they are color related variables):

day begin tint point = 30 (not completely black, but a little fuzzy "light": stars, moon, etc.)
morning astronomical twilight tint point = 40 (a little brighter than full night, but still dark)
morning nautical twilight tint point = 50 (a little brighter than astronomical twilight, but still dark)
morning civil twilight tint point = 60 (a little brighter than nautical twilight, but still dark enough)
sunrise tint point = 160 (this is when the light gets really intense, aka night is becoming day)
sun transit tint point = 255 (full sun luminance, as it's the moment when the sun is at its highest point in the sky)
sunset tint point = 160 (same as sunrise)
evening civil twilight tint point = 60 (same as the opposite twilight)
evening nautical twilight tint point = 50 (same as the opposite twilight)
evening astronomical twilight tint point = 40 (same as the opposite twilight)
"day end" tint point = 30 (same as day begin)

5) Now I calculate the number of minutes between the consecutive points in time during a 24h day when the sky brightness rates are changing, which were listed at 3) (e.g. the number of minutes between "day begin" and "morning astronomical twilight", then the number of minutes between "morning astronomical twilight" and "morning nautical twilight" and so on, until the "day end"). These are necessary for calculations later, at 6).

6) I then calculate the "tint steps", which are defined as "how much does brightness (or tint) change per minute" for the different intervals of the day.

The formula is : Interval Tint Step = (Tint Point of the End of the Interval - Tint Point of the Start of the Interval) / Number of Minutes of the Interval
For example, the "morning civil twilight tint step" = (sunrise tint point - morning civil twilight tint point) / number of minutes of morning civil twilight =
= (160 - 60) / number of minutes of morning civil twilight.

Note : The number of minutes of morning civil twilight is essentially the time difference in minutes betwen morning civil twilight and sunrise.

These "tint steps" are used later in calculating the final tint (brightness) that should be applied to the image of the sky. Bear in mind that because, for example, "evening civil twilight tint point" < "sunset tint point" (60<160), the "tint step" for evening civil twilight will be negative, thus allowing me to "decrease" the brightness in the second part of the day (the part after the sun transit time) in the final calculations below.

7) Finally, I calculate the final brightness/tint that I apply to the sky image:

Tint Color (aka Brightness) = Tint point of the start of the interval I'm in + (Current time - Start of the interval time I'm in) x "Tint step" of the interval I'm in

Note : the (Current time - Start of the interval time) are all measured in minutes.

For example, the formula for calculating the brightness while during the "morning civil twilight"<--->"sunrise" interval would be
Tint Color (aka Brightness) = morning civil twilight tint point + (current time - morning civil twilight time) x "morning civil twilight tint step"

Practical example :
In the case of San Francisco on 22 June 2015, your utility gives 05:17 as the dawn (aka morning civil twilight) time and 05:48 as the sunrise time. Let's say the current time is 05:37. We have:

Number of minutes between "morning civil twilight" and sunrise (determined in step 5)) = 05:48 - 05:17 = 31 minutes
Morning civil twilight tint step (determined in step 6)) = (sunrise tint point - morning civil twilight tint point) / number of minutes of morning civil twilight =
= (160 - 60) / 31 = 100 / 31 = 3.23
Brightness (determined in step 7)) = morning civil twilight tint point + (current time - morning civil twilight time) x "morning civil twilight tint step" =
= 60 + (05:37-05:17) x 3.23 = 60 + 20 x 3.23 = 60 + 64.52 = 124.52

So I'll apply a brightness of 124.52 to the image of the sky if the current time is 05:37. The formula gets recalculated every minute. When going past the sunrise, it gets more radically recalculated, as I enter a different day interval : the one between the sunrise and the sun transit time. So the number of minutes at step 5) changes, and so does the "tint step" at step 6), making the final brightness to change at a different rate per minute compared to the previous interval. The algorithm is applied for the subsequent intervals as well. As I said at step 6), when going past sun transit time, the "tint step" will become negative, as the "tint points" (aka brigthness points) for the end of the intervals are lower then the "tint points" for the start of the same intervals, so when perfoming the subtraction at step 6) I get negative values. This allows the general formula at step 7) to gradually decrease the brightness that's applied to the image of the sky, therefore simulating the coming of the sunset/twilights/night.

Now I'm aware my method is by no means bullet proof, but for my conditions it does its job more than well. The tint point are only approximations and I'm aware that sunrise tint point value should be closer to sun transit tint point value or that the final formula should probably be logarithmic instead of linear, as it is now. I also realize the formula may not be perfectly appropriate for higher latitudes than mine, but that could easily be corrected by multiplying the tint point values with a latitude related variable. The same goes for seasons : if the winter days are, as I suspect, "darker" than the summer days, a similar correction could be enforced. The effect of weather (mainly clouds) on sky brigthness isn't really a concern, at least in what I need to accomplish, as the sky image would be mostly covered by clouds image when this happens, anyway. Calculating sky brightness then would be of no use, because the user would see only a little portion of the sky (which keeps its brightness if we take the clouds/shadows out of the equation).

As for "calculating zenith luminance at solar altitudes less than zero", well, I told you I'm no expert - I'm not sure what you mean by that. If you could try to shortly explain it in a less technical way, it would help.

Hope I could provide a different perspective on the answer you were probably expecting. I guess I anticipated those difficulties when getting info on the "professional method" of calculating sky luminance, otherwise I would have taken that path myself, probably.

P.S. Sorry for the long post.

[Jeff Conrad]

As for "calculating zenith luminance at solar altitudes less than zero", well, I told you I'm no expert - I'm not sure what you mean by that. If you could try to shortly explain it in a less technical way, it would help.

The CIE method for determining sky luminance distribution is based on the luminance of the sky at the zenith. Although the formulas for this luminance vs. Sun altitude are quite simple, the formulas I’ve found are limited to times when the Sun is above the horizon. It’s possible, of course, that the CIE method doesn’t work when the Sun is below the horizon, anyway.

I think the CIE formula is pretty long in the tooth, so there well may be better methods available now. I just haven’t found one ...

I’ve long wondered when someone would provide a VR application that accurately represents the luminance and color of the twilight sky—Google Earth is an interesting start, but it’s definitely not there yet. Someone else well may have done it. But twilight is pretty tricky; as far as I know, the definitive treatise is still Georgii Rozenberg’s 1966 book.

As it turns out, adding a parameter to suppress the Sun/Moon Calculator’s main form wasn’t the difficult. Nor was adding an option to show astronomical and nautical twilight. The devil is always in the details, of course—including updates to the documentation and making sure that something isn’t inadvertently broken. I hope to have a beta posted in a day or so.

[Yincognyto]

As it turns out, adding a parameter to suppress the Sun/Moon Calculator’s main form wasn’t the difficult. Nor was adding an option to show astronomical and nautical twilight. The devil is always in the details, of course—including updates to the documentation and making sure that something isn’t inadvertently broken. I hope to have a beta posted in a day or so.

Wow, that's fantastic! Can't wait to test it (and hopefully use it in my weather skin)! Thank you!

[Jeff Conrad]

Adding a parameter to suppress the Sun/Moon Calculator’s main form was straightforward, but setting things up so that a GET would produce readily captured output is not, mainly because of the way client-side JavaScript works nowadays. Capture might still be possible with IE 8, but I would not wish that browser on anyone—especially for use with the Sun/Moon Calculator, because the JavaScript performance is politely described as abysmal. So—at least for now—it isn’t happening.

I did add the ability to show the times of astronomical and nautical twilight, as well as a few other features. The release version is now posted.

[Yincognyto]

I did add the ability to show the times of astronomical and nautical twilight, as well as a few other features. The release version is now posted.

I just tried the Sun/Moon Calculator and it's exactly as it was before (that is, no astronomical and nautical twilights - aka the "old version"). Maybe I tried too soon? Or does this require an additional parameter?

[Jeff Conrad]

It’s a user preference that needs to be set manually. It’s sticky, though, so at the next invocation with parameters, the additional times should be displayed. The new version clears any previously set preferences on first loading, so if any were set to other than default, they need to be set again. But it should be a one-time procedure.

[Jeff Conrad]

It’s arguably messy to have to manually set options for a programmatic invocation. I’ve added parameters to set several User Preferences at invocation; they have the same effect as setting these options on the User Preferences form, so they’re retained across invocations. Give tw=a to show all twilight times.

The new parameters represent only a small fraction of the available User Preference options, but the others are arguably less important for programmatic invocation. Moreover, I suspect the number of people who use the parameter interface can easily be counted on both hands.

[Alan Klein]

Jeff: I've been using TPE on my Samsung Galaxy S4 for awhile now. What advantages with yours? Thanks.

[Jeff Conrad]

Alan,

There may not be an advantage. But the only version of TPE that I’ve used is the desktop app (both old and new), so it’s tough to give a solid answer.

It looks to me as if the Android app is missing a number of the features on the TPE for iOS 3, but to be honest, I’m not that familiar with the Android version—all I know is in the introductory video. I don’t know what is planned for the Android app.

Currency
The first thing I would observe is that the Sun/Moon Calculator is very much a legacy application, which should be evident from the layout. It’s had some significant updates since 1998, but it makes no attempt to function as a mobile app. I’ve actually never tried it, but doubt I would be impressed. So if you want to use it on your phone, I think it’s an easy decision. I prefer to do planning on a larger canvas, but perhaps I’m just a legacy user.

Map Integration
Next, the Sun/Moon Calculator doesn’t integrate the Sun and Moon data with the map. You can open the TPE desktop app or the Sun/Moon Calculator’s Az/Alt Tool to the calculator’s current location but it’s an extra step. And there is no synchronization between the calculator and either of the other apps. Depending on how you work, this may or may not be an issue.

Depending on what you do, using a map at some point would seem almost unavoidable, so TPE has the advantage of being map-centric. I’ve used digital maps (National Geographic TOPO!) since early 1997, when Google Maps and TPE were years in the future. But TOPO! is long defunct (a sad story ...), so it’s no longer an option. And with TPE and my Az/Alt Tool, you get the ability to get the altitude to a feature as well as the azimuth and distance—an essential capability if you want to align the Sun or Moon with a feature. Most other programs just weren’t written for photographers.

Features in the Sun/Moon Calculator
If the video represents all that’s available on the Android app, the Sun/Moon Calculator does have one notable additional feature: the ability to find dates on which the Sun or Moon is within a certain range of azimuth and altitude. If you do this sort of thing, it’s a big advantage; if you don’t, it’s of no value.

Features in TPE for iOS 3
The iOS 3 version of TPE seems to have several features not available for Android, including


The ability to find dates on which the Sun or Moon is in a certain position. It’s somewhat different from my date search; mine is more flexible, but more work to set up, as many have told me ...

The ability to adjust elevation data that are suspect (digital elevation models are a work in progress), and the ability to specify the height above ground of man-made structures. The latter is especially handy if you want to align the Sun or Moon with a building.


And the iOS version seems to be very nicely implemented—you might want to look at some of the video tutorials—they might even make you want a new iPhone or iPad ...

So I’m not sure there’s a good answer to your question—it’s very much a matter of personal preference and the type of photography you do. TPE is a great app, so you’re already pretty well covered.

[Alan Klein]

Actually you just reminded my that my wife has an iPad. I could try TPE on it to see how it works. But I'm not sure if that would work. Does an iPad have built in compass like a smart phone? Do you need a compass to operate your program?

[Jeff Conrad]

Alan,

I’d much rather plan a shot on an iPad than on a smartphone—simply because of canvas size. Note that you need iOS 8.1 or later. If you have that covered, you should be fine. I think you would find at least some of the features useful—and for nine bucks, how can you go wrong?

iPad manuals seem to indicate that all iPads have had compasses, but I don’t have an iPad, so I can’t comment from experience. I’m not sure the compass is that important, though. If a shot requires careful planning, you need to do the planning before you arrive at a location. And you’ll usually get much better results from geodetic calculations (the grey marker in TPE) than from pointing a compass—electronic or ancient.

A compass is irrelevant to the Sun/Moon Calculator, which is too ancient to be aware of such things. A compass may be helpful if you need to make field measurements, but as I mentioned, you’ll usually get better results determining directions with geodetic calculations, using either TPE or my Az/Alt Tool. A compass may be helpful once you get to the field; I use one (a venerable Silva Ranger) on which I can compensate for magnetic declination. Most electronic compasses are supposed to handle this automatically, but I don’t know what happens with an iPad.

There is no reason you can’t use both TPE and the Sun/Moon Calculator. You may find that you prefer one or the other, or you may find that one is better for some things and the other is better for others. If you want to find days on which the Sun or Moon is within specified ranges of azimuth and altitude, the Sun/Moon Calculator is the only show in town. For most other things, you’d probably prefer TPE. Judging from your Flickr albums, you don’t seem to be OCD on lining up the Sun or Moon with a mountain or building, so my calculator may not do much for you.

In any event, if your wife’s iPad has 8.1 or later, getting TPE for it would seem a no-brainer.