diff options
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | python-sgp4.spec | 245 | ||||
| -rw-r--r-- | sources | 1 |
3 files changed, 247 insertions, 0 deletions
@@ -0,0 +1 @@ +/sgp4-2.21.tar.gz diff --git a/python-sgp4.spec b/python-sgp4.spec new file mode 100644 index 0000000..6ff4546 --- /dev/null +++ b/python-sgp4.spec @@ -0,0 +1,245 @@ +%global _empty_manifest_terminate_build 0 +Name: python-sgp4 +Version: 2.21 +Release: 1 +Summary: Track Earth satellites given TLE data, using up-to-date 2020 SGP4 routines. +License: MIT +URL: https://github.com/brandon-rhodes/python-sgp4 +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/0e/20/a28ed2ffd30dcb3f090f636b5d110ffd148e8d26238987b3cdfaea6501b7/sgp4-2.21.tar.gz + + +%description +This library uses the same function names as the official C++ code, to +help users who may already be familiar with SGP4 in other languages. +Here is how to compute the x,y,z position and velocity for the +International Space Station at 12:50:19 on 29 June 2000: +>>> from sgp4.api import Satrec +>>> +>>> s = '1 25544U 98067A 19343.69339541 .00001764 00000-0 38792-4 0 9991' +>>> t = '2 25544 51.6439 211.2001 0007417 17.6667 85.6398 15.50103472202482' +>>> satellite = Satrec.twoline2rv(s, t) +>>> +>>> jd, fr = 2458827, 0.362605 +>>> e, r, v = satellite.sgp4(jd, fr) +>>> e +0 +>>> print(r) # True Equator Mean Equinox position (km) +(-6102.44..., -986.33..., -2820.31...) +>>> print(v) # True Equator Mean Equinox velocity (km/s) +(-1.45..., -5.52..., 5.10...) +As input, you can provide either: +* A simple floating-point Julian Date for ``jd`` and the value 0.0 for + ``fr``, if you are happy with the precision of a 64-bit floating point + number. Note that modern Julian Dates are greater than 2,450,000 + which means that nearly half of the precision of a 64-bit float will + be consumed by the whole part that specifies the day. The remaining + digits will provide a precision for the fraction of around 20.1 µs. + This should be no problem for the accuracy of your result — satellite + positions usually off by a few kilometers anyway, far less than a + satellite moves in 20.1 µs — but if you run a solver that dives down + into the microseconds while searching for a rising or setting time, + the solver might be bothered by the 20.1 µs plateau between each jump + in the satellite’s position. +* Or, you can provide a coarse date ``jd`` plus a very precise fraction + ``fr`` that supplies the rest of the value. The Julian Date for which + the satellite position is computed is the sum of the two values. One + common practice is to provide the whole number as ``jd`` and the + fraction as ``fr``; another is to have ``jd`` carry the fraction 0.5 + since UTC midnight occurs halfway through each Julian Date. Either + way, splitting the value allows a solver to run all the way down into + the nanoseconds and still see SGP4 respond smoothly to tiny date + adjustments with tiny changes in the resulting satellite position. +Here is how to intrepret the results: +* ``e`` will be a non-zero error code if the satellite position could + not be computed for the given date. You can ``from sgp4.api import + SGP4_ERRORS`` to access a dictionary mapping error codes to error + messages explaining what each code means. +* ``r`` measures the satellite position in **kilometers** from the + center of the earth in the idiosyncratic True Equator Mean Equinox + coordinate frame used by SGP4. +* ``v`` velocity is the rate at which the position is changing, + expressed in **kilometers per second**. +If your application does not natively handle Julian dates, you can +compute ``jd`` and ``fr`` from calendar dates using ``jday()``. +>>> from sgp4.api import jday +>>> jd, fr = jday(2019, 12, 9, 12, 0, 0) +>>> jd +2458826.5 +>>> fr +0.5 + +%package -n python3-sgp4 +Summary: Track Earth satellites given TLE data, using up-to-date 2020 SGP4 routines. +Provides: python-sgp4 +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +BuildRequires: python3-cffi +BuildRequires: gcc +BuildRequires: gdb +%description -n python3-sgp4 +This library uses the same function names as the official C++ code, to +help users who may already be familiar with SGP4 in other languages. +Here is how to compute the x,y,z position and velocity for the +International Space Station at 12:50:19 on 29 June 2000: +>>> from sgp4.api import Satrec +>>> +>>> s = '1 25544U 98067A 19343.69339541 .00001764 00000-0 38792-4 0 9991' +>>> t = '2 25544 51.6439 211.2001 0007417 17.6667 85.6398 15.50103472202482' +>>> satellite = Satrec.twoline2rv(s, t) +>>> +>>> jd, fr = 2458827, 0.362605 +>>> e, r, v = satellite.sgp4(jd, fr) +>>> e +0 +>>> print(r) # True Equator Mean Equinox position (km) +(-6102.44..., -986.33..., -2820.31...) +>>> print(v) # True Equator Mean Equinox velocity (km/s) +(-1.45..., -5.52..., 5.10...) +As input, you can provide either: +* A simple floating-point Julian Date for ``jd`` and the value 0.0 for + ``fr``, if you are happy with the precision of a 64-bit floating point + number. Note that modern Julian Dates are greater than 2,450,000 + which means that nearly half of the precision of a 64-bit float will + be consumed by the whole part that specifies the day. The remaining + digits will provide a precision for the fraction of around 20.1 µs. + This should be no problem for the accuracy of your result — satellite + positions usually off by a few kilometers anyway, far less than a + satellite moves in 20.1 µs — but if you run a solver that dives down + into the microseconds while searching for a rising or setting time, + the solver might be bothered by the 20.1 µs plateau between each jump + in the satellite’s position. +* Or, you can provide a coarse date ``jd`` plus a very precise fraction + ``fr`` that supplies the rest of the value. The Julian Date for which + the satellite position is computed is the sum of the two values. One + common practice is to provide the whole number as ``jd`` and the + fraction as ``fr``; another is to have ``jd`` carry the fraction 0.5 + since UTC midnight occurs halfway through each Julian Date. Either + way, splitting the value allows a solver to run all the way down into + the nanoseconds and still see SGP4 respond smoothly to tiny date + adjustments with tiny changes in the resulting satellite position. +Here is how to intrepret the results: +* ``e`` will be a non-zero error code if the satellite position could + not be computed for the given date. You can ``from sgp4.api import + SGP4_ERRORS`` to access a dictionary mapping error codes to error + messages explaining what each code means. +* ``r`` measures the satellite position in **kilometers** from the + center of the earth in the idiosyncratic True Equator Mean Equinox + coordinate frame used by SGP4. +* ``v`` velocity is the rate at which the position is changing, + expressed in **kilometers per second**. +If your application does not natively handle Julian dates, you can +compute ``jd`` and ``fr`` from calendar dates using ``jday()``. +>>> from sgp4.api import jday +>>> jd, fr = jday(2019, 12, 9, 12, 0, 0) +>>> jd +2458826.5 +>>> fr +0.5 + +%package help +Summary: Development documents and examples for sgp4 +Provides: python3-sgp4-doc +%description help +This library uses the same function names as the official C++ code, to +help users who may already be familiar with SGP4 in other languages. +Here is how to compute the x,y,z position and velocity for the +International Space Station at 12:50:19 on 29 June 2000: +>>> from sgp4.api import Satrec +>>> +>>> s = '1 25544U 98067A 19343.69339541 .00001764 00000-0 38792-4 0 9991' +>>> t = '2 25544 51.6439 211.2001 0007417 17.6667 85.6398 15.50103472202482' +>>> satellite = Satrec.twoline2rv(s, t) +>>> +>>> jd, fr = 2458827, 0.362605 +>>> e, r, v = satellite.sgp4(jd, fr) +>>> e +0 +>>> print(r) # True Equator Mean Equinox position (km) +(-6102.44..., -986.33..., -2820.31...) +>>> print(v) # True Equator Mean Equinox velocity (km/s) +(-1.45..., -5.52..., 5.10...) +As input, you can provide either: +* A simple floating-point Julian Date for ``jd`` and the value 0.0 for + ``fr``, if you are happy with the precision of a 64-bit floating point + number. Note that modern Julian Dates are greater than 2,450,000 + which means that nearly half of the precision of a 64-bit float will + be consumed by the whole part that specifies the day. The remaining + digits will provide a precision for the fraction of around 20.1 µs. + This should be no problem for the accuracy of your result — satellite + positions usually off by a few kilometers anyway, far less than a + satellite moves in 20.1 µs — but if you run a solver that dives down + into the microseconds while searching for a rising or setting time, + the solver might be bothered by the 20.1 µs plateau between each jump + in the satellite’s position. +* Or, you can provide a coarse date ``jd`` plus a very precise fraction + ``fr`` that supplies the rest of the value. The Julian Date for which + the satellite position is computed is the sum of the two values. One + common practice is to provide the whole number as ``jd`` and the + fraction as ``fr``; another is to have ``jd`` carry the fraction 0.5 + since UTC midnight occurs halfway through each Julian Date. Either + way, splitting the value allows a solver to run all the way down into + the nanoseconds and still see SGP4 respond smoothly to tiny date + adjustments with tiny changes in the resulting satellite position. +Here is how to intrepret the results: +* ``e`` will be a non-zero error code if the satellite position could + not be computed for the given date. You can ``from sgp4.api import + SGP4_ERRORS`` to access a dictionary mapping error codes to error + messages explaining what each code means. +* ``r`` measures the satellite position in **kilometers** from the + center of the earth in the idiosyncratic True Equator Mean Equinox + coordinate frame used by SGP4. +* ``v`` velocity is the rate at which the position is changing, + expressed in **kilometers per second**. +If your application does not natively handle Julian dates, you can +compute ``jd`` and ``fr`` from calendar dates using ``jday()``. +>>> from sgp4.api import jday +>>> jd, fr = jday(2019, 12, 9, 12, 0, 0) +>>> jd +2458826.5 +>>> fr +0.5 + +%prep +%autosetup -n sgp4-2.21 + +%build +%py3_build + +%install +%py3_install +install -d -m755 %{buildroot}/%{_pkgdocdir} +if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi +if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi +if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi +if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi +pushd %{buildroot} +if [ -d usr/lib ]; then + find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/lib64 ]; then + find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/bin ]; then + find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/sbin ]; then + find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst +fi +touch doclist.lst +if [ -d usr/share/man ]; then + find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst +fi +popd +mv %{buildroot}/filelist.lst . +mv %{buildroot}/doclist.lst . + +%files -n python3-sgp4 -f filelist.lst +%dir %{python3_sitearch}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Mon Apr 10 2023 Python_Bot <Python_Bot@openeuler.org> - 2.21-1 +- Package Spec generated @@ -0,0 +1 @@ +a7b91d40cdff9087ff73a22e325e41fb sgp4-2.21.tar.gz |