Version 3.7.6.0:
The new ephem.cities.lookup() function runs a Google geocoding search and returns an Observer object for the top result.
When an Earth satellite position cannot be computed, PyEphem now raises an exception instead of freezing and locking up Python.
Upgraded to the libastro from XEphem 3.7.6, bringing improvements to Earth satellite transit calculations.
GitHub issue 76: Earth satellite velocity is now calculated with greater accuracy.
GitHub issue 64: rising and setting routines are now careful to restore your Observer.date even if they die with an exception.
GitHub issue 56: Earth satellites now raise an exception for dates a year or more from their TLE epoch, because libastro refuses to process old elements and would return nonsense coordinates.
GitHub issue 44: a segmentation fault would eventually kill Python 3 if a script called Body.copy() either directly or via the Standard Library copy.copy() function.
Based on PR#43737 by Kamel Derouiche.
remove RESTRICTION, because COPYING file said GPL or LGPL, nothing for others.
PyEphem CHANGELOG
=================
Version 3.7.3.4 (2009 April 30)
-------------------------------
- Added a new ``next_pass()`` method to ``Observer`` that searches for
when a satellite next rises, culminates, and sets.
- Added a ``compute_pressure()`` method to ``Observer`` which computes
the standard atmospheric pressure at the observer's current elevation.
This function now gets called automatically on new ``city()`` objects
before they are returned to the user.
- Corrected the altitude of San Francisco as returned by ``city()``.
- Improved the copyright message so that two more authors are credited.
Version 3.7.3.3 (2008 October 3)
--------------------------------
- Added ``cmsI`` and ``cmsII`` attributes to ``Jupiter`` to provide the
central meridian longitude in both System I and System II.
- **Bugfix**: Saturn was returning the wrong values for its earthward
and sunward angle tilt.
Version 3.7.3.2 (2008 July 2)
-----------------------------
- **Bugfix**: the rising and setting functions, if called repeatedly,
would sometimes get hung up on a single answer which they would return
over and over again instead of progressing to the next rising or
setting. They should now always progress instead of getting stuck.
Version 3.7.3.1 (2008 July 1)
-----------------------------
- **Bugfix**: the rising and setting functions were attempting to
achieve such high precision that users sometimes found circumstances
under which they would not complete at all! They now stop and return
an answer once they are withing a half-second of the real time of
rising, transit, or setting, which solves the problem without damaging
the quality of the results when tested against the Naval Observatory.
- Upgraded to the libastro from XEphem 3.7.3.
Version 3.7.2.4 (2008 June 12)
------------------------------
- **Incompatible Change**: After feedback from users, I have changed
the ``Observer`` methods which find risings, settings, and transits,
so that they do not change their Observer's ``.date`` attribute. So
the sequence:
.. code-block:: python
r1 = boston.next_rising(mars)
r2 = boston.next_rising(mars)
now computes the same value twice! If you want a series of calls to
each begin when the other left off, you can use the ``start=``
parameter described in the next item:
.. code-block:: python
r1 = boston.next_rising(mars)
r2 = boston.next_rising(mars, start=r1)
- Added an optional ``start=`` argument to the rising, setting, and
transit ``Observer`` functions, that tells them from which date and
time to begin their search.
- **Bugfix**: Rewrote planetary moon routines so that moons of Mars,
Jupiter, Saturn, and Uranus now return appropriate data for years
1999-2020. (Each moon had been returning the unmodified position of
its planet, because I was unsure whether I could distribute the moon
data with PyEphem.)
- You can no longer create arbitrary attributes on an ``Observer``, to
prevent users from accidentially saying things like
``here.longitude`` or ``here.lon`` when they mean ``here.long``.
Create your own subclass of ``Observer`` if you need the power to
set your own attributes.
- The ephem module now provides a ``__version__`` symbol.
- Added test suite that tests planet and planet moon positions
against JPL ephemeris data (needs more work).
Version 3.7.2.3 (2008 January 8)
--------------------------------
- Three new classes ``Equatorial``, ``Ecliptic``, and ``Galactic``
allow coordinates to be transformed between the three systems
(ability to transform coordinates was requested by Aaron Parsons).
- Added constants for popular epochs ``B1900``, ``B1950``, and
``J2000``.
- Added named functions for every solstice and equinox (before, only
the vernal equinox could be asked for specifically).
- Product tests have been moved inside of the ``ephem`` module itself,
and can now be invoked simply by running:
.. code-block:: bash
$ python setup.py test
- **Bugfix**: ``Angle()`` can no longer be directly instantiated.
- **Bugfix**: San Francisco had the wrong coordinates in the cities
database (pointed out by Randolph Bentson).
Version 3.7.2.2 (2007 December 9)
---------------------------------
- The phases of the moon can now be determined through the functions
``next_new_moon()``, ``next_full_moon()``, ``previous_new_moon()``,
et cetera.
- Added a modest database of world cities; the ``city()`` function
returns a new Observer on each call:
.. code-block:: python
observer = ephem.city('Boston')
- Using the old ``rise``, ``set``, and ``transit`` attributes on
``Body`` objects now causes a deprecation warning.
- **Bugfix**: the last release of PyEphem omitted the constants
``meters_per_au``, ``earth_radius``, ``moon_radius``, and
``sun_radius``; the constant ``c`` (the speed of light) is also now
available.
Version 3.7.2.1 (2007 October 1)
--------------------------------
- Functions now exist to find equinoxes and solstices.
- Bodies now cleanly offer three different versions of their
position, rather than making the user remember obscure rules for
having each of these three values computed:
* Astrometric geocetric right ascension and declination
* Apparent geocentric right ascension and declination
* Apparent topocentric right ascension and declination
- Bodies can now find their next or previous times of transit,
anti-transit, rising, and setting.
- A ``localtime()`` function can convert PyEphem ``Date`` objects to
local time.
- Now ``ephem.angle`` instances can survive unary ``+`` and ``-``
without getting changed into plain floats.
- The ``elev`` Observer attribute has been renamed to ``elevation``.
- Observers now display useful information when printed.
- Added a much more extensive test suite, which, among other things,
now compares results with the United States Naval Observatory,
insisting upon arcsecond agreement.
- **Bugfix**: When a fixed body is repeatedly precessed to different
dates, its original position will no longer accumulate error.
Version 3.7.2a (2007 June)
--------------------------
- Upgraded to the libastro from XEphem 3.7.2.
- Should now compile under Windows!
- **Bugfix**: rewrote date-and-time parsing to avoid the use of
``sscanf()``, which was breaking under Windows and requiring the
insertion of a leading space to succeed.
- Improved the error returned when a date string cannot be parsed,
so that it now quotes the objectionable string (so you can tell
which of several date strings on the same line gave an error!).
This changes the buildlink3.mk files to use an include guard for the
recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS,
BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new
variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of
enter/exit marker, which can be used to reconstruct the tree and
to determine first level includes. Avoiding := for large variables
(BUILDLINK_ORDER) speeds up parse time as += has linear complexity.
The include guard reduces system time by avoiding reading files over and
over again. For complex packages this reduces both %user and %sys time to
half of the former time.
- assume that Python 2.4 and 2.5 are compatible and allow checking for
fallout.
- remove PYTHON_VERSIONS_COMPATIBLE that are obsoleted by the 2.3+
default. Modify the others to deal with the removals.
