Re: [boost] Is Boost.Astronomy feasible?

Subject: Re: [boost] Is Boost.Astronomy feasible?
From: Mika Heiskanen (mika.heiskanen_at_[hidden])
Date: 2008-11-05 16:35:28

Matthias Schabel wrote:

> Methods for getting all sunrises/sunsets within a given time window 
> would make sense to me.

Personally I would like the API to be as easy to use as possible.
However, I really do not have any solid ideas on what the best API
should be. I am merely disappointed by the existing ones I have
used so far.

>> o What is the definition for the length of the day if sunrise/sunset
>>    occurs more than once during a day?
> 
> Again, a method for getting the interval between sunset and sunrise 
> within a given time window
> would sidestep this issue.

Calculating the amount of daylight should be as easy as possible, and simply
returning the sunrise/sunset times from the lower API does not make
it as easy as possible. What is the minimum time window you have to give as
input to determine the full status of any given date? If the date in question
contains the first solar event after a long polar day/night, the relevant time
window may be months long.

>>  o Are separate methods needed for testing whether the given date
>>    is of type "polar day" or "polar night" or "midnight sun"?
>>    The definitions for the three seem to be a bit ambiguous. For
>>    example, it is perfectly possible for the sun to be up at midnight
>>    but still to set during the day, in which case you would have
>>    "midnight sun" but not necessarily a "polar day", when the sun
>>    shines 24h.
> 
> I would expect methods to query whether the sun is up or down at a given 
> time/geographic location.
> Special functionality for polar regions could be built on top of that...

One needs to calculate all relevant nearby sunrise/sunset events to
determine the "state" of a queried date. The calculations are not
a problem, provided an API exists for calculating all events during
a time interval. The problem is that atleast I personally do not
know whether the definitions of polar day etc are official, de facto
or whatever. Clearly only one definition must exist as far as
the code is concerned.

>>  o Would a boost::astronomy namespace as implied above be
>>    a good addition to boost?
> 
> I would vote for boost::astrometry.

Or boost::sun and boost::moon? Not being a native English speaker
I myself had never heard of astrometry before this. Having checked
out the Wiki pages etc it makes sense, but I do believe more
plain names such as boost::sun would be more recognizable for
common users.

> I have a fair amount of experience with astrometry software, but not 
> tons of free time. I would be
> happy to discuss interface issues and, where possible, to point you to 
> existing implementations
> that might be useful. Be forewarned : this is likely to become a much 
> bigger undertaking than it
> seems. To do all this correctly would require support for vector 
> geometry, GIS, multiple time systems,
> etc... I would recommend trying to add some of the basic sunrise/set 
> functionality to Date-Time
> first and see how that goes...

1. I do not see why external vector geometry support is needed.

2. Why GIS? To define the datum? If we cannot assume a fixed
    datum such as WGS84, we seem to be in trouble already.

3. Multiple time systems should be taken care of by Boost.DateTime.

As for understanding that this may be "a bigger undertaking than it seems",
I understand it perfectly well. I know that I do not know what the best
formulas are, nor do I know what the API should look like. Definitely
not the best place to be in. I just know the functionality is needed.

--> Mika Heiskanen