Hello, I would like to think that it would be possible to create a library for common astronomical calculations, and I think boost might be the proper place to create one for the C++ community. First a definition: by common calculations I mean those most relevant to every dat life. For normal people this would pretty much exclude most astronomical calculations except those concerning the sun and the moon. Some examples on what calculations I think would be common are: o sunrise, sunset, noon o sun elevation, azimuth, declination o length of the day o phase of the moon, and whether the visible fraction is increasing or not However, there are some complications: o There are several ways to define twilight times, for example civil, nautical and astronomical. o The sun may set/rise more than once during a day in polar regions, or it may do neither. o What is the definition for the length of the day if sunrise/sunset occurs more than once during a day? 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. o Most calculations are intimately tied to the local time, so the API should rely on Boost.Date_time. Many places refer to Meeus's work for the most accurate calculations. The formulas have been ported to C++ in the form of the AA++ (astronomical algorithms) library. However, the library seems to be aimed for experts and there are no easy recipies for solving the common problems mentioned above. The questions I would like to pose are then: o Would a boost::astronomy namespace as implied above be a good addition to boost? o Are there any experts out there who understand the subject matter well enough to provide a robust implementation or atleast guidance on the matter? For example, NOAA provides web based solar position and sunrise calculators. According to the documentation the calculators are based on the work of Meeus. However, there are some clear design issues on how things should be handled in C++ versus the JavaScript embedded into the NOAA pages. Any thoughts on the matter? Regards, --> Mika Heiskanen
Mika Heiskanen wrote:
I would like to think that it would be possible to create a library for common astronomical calculations, and I think boost might be the proper place to create one for the C++ community.
You might want to look into how it could integrate with geometry libraries, if that is useful. There has been much discussion about computational geometry libraries candidates for Boost. Of course integration with Boost.DateTime would be useful for all kinds of date/time operations.
However, there are some complications:
o There are several ways to define twilight times, for example civil, nautical and astronomical.
Isn't that just a matter of units?
o The sun may set/rise more than once during a day in polar regions, or it may do neither.
o What is the definition for the length of the day if sunrise/sunset occurs more than once during a day?
To me, the length of the day doesn't depend on sunrise/sunset but on the time the Earth takes to perform a rotation on its axis. That is to say it doesn't vary. (or it varies but so slowly that we don't care) The duration of sunlight during the day or the time between a sunset and its previous sunrise might also be interesting, but they're not really days anymore, but rather durations of daylight.
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 have no idea what makes the most sense, I know nothing of astronomy. In any case, all things should be clearly modelled and documented with non-ambiguous definitions.
o Would a boost::astronomy namespace as implied above be a good addition to boost?
I suppose any finely crafted C++ library with a liberal license and which has its use has its place in boost. As a side note, shouldn't an astronomy library take care of handling celestial bodies in the universe, and thus model their physical interactions with relativity theory? Maybe an Earth-centric library should be given another more restricted name, more tied to its scope.
Mathias Gaunard wrote:
You might want to look into how it could integrate with geometry libraries, if that is useful.
I do not see how geometry libraries would be relevant in this matter. The formulas for most of the astronomical calculations seem to be mostly numerical approximations. Could you elaborate?
o There are several ways to define twilight times, for example civil, nautical and astronomical.
Isn't that just a matter of units?
Yes, but the API must take it into account.
The duration of sunlight during the day or the time between a sunset and its previous sunrise might also be interesting, but they're not really days anymore, but rather durations of daylight.
Many newspapers will report the duration of daylight. In my own language the newspapers usually report the number as the "length of the day". Any implementation would have to define what exactly the term means. Duration of daylight seems non-ambiguous to me.
As a side note, shouldn't an astronomy library take care of handling celestial bodies in the universe, and thus model their physical interactions with relativity theory? Maybe an Earth-centric library should be given another more restricted name, more tied to its scope.
boost::sun and boost::moon ? --> Mika Heiskanen
At 5:47 PM +0200 11/5/08, Mika Heiskanen wrote:
Hello,
I would like to think that it would be possible to create a library for common astronomical calculations, and I think boost might be the proper place to create one for the C++ community.
First a definition: by common calculations I mean those most relevant to every dat life. For normal people this would pretty much exclude most astronomical calculations except those concerning the sun and the moon.
Some examples on what calculations I think would be common are:
o sunrise, sunset, noon
o sun elevation, azimuth, declination
o length of the day
o phase of the moon, and whether the visible fraction is increasing or not
I think this is a great idea! I encourage you to take this idea and run with it. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
Some examples on what calculations I think would be common are:
o sunrise, sunset, noon
o sun elevation, azimuth, declination
o length of the day
o phase of the moon, and whether the visible fraction is increasing or not
Many of these types of calculations fall under the general domain of "astrometry" rather than astronomy. I think this would be a very interesting addition to Boost, though, like any non-trivial problem domain, it will be a challenge to find the appropriate balance between feature-richness and excessive mission creep... Some of the functionality listed here might be most sensible as an inclusion to Boost Date/Time...
o The sun may set/rise more than once during a day in polar regions, or it may do neither.
Methods for getting all sunrises/sunsets within a given time window would make sense to me.
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.
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...
Many places refer to Meeus's work for the most accurate calculations. The formulas have been ported to C++ in the form of the AA++ (astronomical algorithms) library. However, the library seems to be aimed for experts and there are no easy recipies for solving the common problems mentioned above.
Meeus' book is a good one. Another good source for astrometry code/ information is the Naval Observatory Vector Astrometry Subroutines (NOVAS) library - this is more focused on astrometry, but would be helpful if you wanted the library to support moonrise/ moonset or rise/set times for planets.
o Would a boost::astronomy namespace as implied above be a good addition to boost?
I would vote for boost::astrometry.
o Are there any experts out there who understand the subject matter well enough to provide a robust implementation or atleast guidance on the matter?
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... Matthias
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
Mika Heiskanen wrote:
2. Why GIS? To define the datum? If we cannot assume a fixed datum such as WGS84, we seem to be in trouble already.
After a quick check - according to http://coding.derkeiler.com/Archive/Perl/comp.lang.perl.modules/2005-10/msg0... Meeus does not use a standard ellipsoid. --> Mika Heiskanen
I've been thinking about this since I saw the first post on the subject. Please excuse my curmudgeonly attitude, but I think this should be said. I would say that adding an astrometry (or astrometry, or astrology for that matter) library to Boost is a step in the wrong direction. Where I work, we use the Boost libraries to develop our commercial software. Because we want to "release" official Boost versions into our development environment, we build the linkable libraries and check them into our source code repository. We also check the header files into the repository. When I do a checkout, the largest amount of time and disk space goes to checking out the Boost libraries and headers. I just looked and the include/boost directory contains 20,747 files. In my opinion, the last thing Boost needs is more library binaries and more header files for a library that will be of very little general use. The Boost libraries started out (as near as I can tell) as a way to get capabilities into C++ that were left out of the standard. They do that admirably, and they are being used as the basis for a lot of C+ +0x additions. I love them and I thank the developers from the bottom of my heart for what they have created. But there also seems to be a tendency to want to throw in everything, including the kitchen sink. I would suggest avoiding that and keeping the libraries focused on solving programming problems faced by most C++ programmers. I just don't think that common astronomy calculations fall into that category. Just my 2 cents. - Rush
Rush Manbert wrote:
I would say that adding an astrometry (or astrometry, or astrology for that matter) library to Boost is a step in the wrong direction.
[...] In my opinion, the last thing Boost needs is more library binaries and more header files for a library that will be of very little general use.
I wanted to say that there are already a lot of libraries that are fairly specific, but it's true none are as specific as astrometry. I think Boost is having problems dealing with its huge size anyway, so eventually libraries will have to be made separate packages or something. I'm thinking more of a CPAN-like system. More and more Boost libraries are also distributed as standalone by their authors.
participants (5)
-
Marshall Clow -
Mathias Gaunard -
Matthias Schabel -
Mika Heiskanen -
Rush Manbert