1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
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
* Fri Apr 21 2023 Python_Bot <Python_Bot@openeuler.org> - 2.21-1
- Package Spec generated
|
