%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 * Fri Apr 21 2023 Python_Bot - 2.21-1 - Package Spec generated