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