This enables a new class Astronoby::Events::ObservationEvents to expose observation events such as rising time, setting azimuth, transit altitude, ...
It is not meant to be used directly (but it is technically possible) as it requires a set of equatorial coordinates for 3 consecutive days, which is not very convenient for the developer, but called by body classes (such as Astronoby::Sun and other classes coming soon) to expose a well documented object.
This change has two main goals:
Have a common API for all bodies regarding observation events: every body in the sky is entitled to expose these times and angles, but it doesn't make sense to have to implement these methods on each class. Instead, ObservationEvents acts like a common presenter.
This implementation allows for a natural memoization as calling sun.observation_events returns on object on which all the data is already computed and accessible.
To keep related tests together, the tests related to the Sun are still in sun_spec.rb. This avoid having observation_events_spec.rb having thousands of lines.
This enables a new class
Astronoby::Events::ObservationEvents
to expose observation events such as rising time, setting azimuth, transit altitude, ...It is not meant to be used directly (but it is technically possible) as it requires a set of equatorial coordinates for 3 consecutive days, which is not very convenient for the developer, but called by body classes (such as
Astronoby::Sun
and other classes coming soon) to expose a well documented object.This change has two main goals:
ObservationEvents
acts like a common presenter.sun.observation_events
returns on object on which all the data is already computed and accessible.To keep related tests together, the tests related to the Sun are still in
sun_spec.rb
. This avoid havingobservation_events_spec.rb
having thousands of lines.This change opens new opportunities like creating a
Star
body class, and extracting the twilight methods fromSun
into a similar class.Fixes #58