問題タブ [pyephem]

観測者の緯度/経度の数値はラジアンとして扱われ、文字列値は 10 進度として扱われるという決定がなされたのはなぜですか?

Python で緯度/経度の値を扱うとき、私は通常、float オブジェクトを扱います。星が正しく配置されている場合、そこに 1 つまたは 2 つの int オブジェクトが浮いている可能性がありますが、ほとんどは浮いています。私はいつも次のような単純なコードを書くことになります：

そして、私は火傷します。緯度/経度の値がラジアンではなく 10 進数であるため、火傷を負ってしまいます。自分が何を間違えたのかと頭を悩ませてしまうので、通常は悪いことです。最後に、ラジアンに変換することになります。理論的には、これを実行して正しい結果を得ることができます。

しかし、それも不安定に思えます。私の値はラジアンでなければならないと思っていました! フロートの場合のみ。文字列または浮動小数点オブジェクトを受け入れることは素晴らしいことですが、python 型に基づいて異なる数値型を受け入れることは矛盾しているようです。次のように、両方の代入が同じ数値型を取ることを期待します。

次に、10 進度 / dms の変換演算子を指定できます。

次に、to_rad 関数は、10 進度が float または string オブジェクトとして提供されていることを明示的に想定します。この時点で、インターフェイスは一貫しています。私は _libastro.c を簡単に掘り下げて、この質問の核心にある to_angle 関数を調べました。

これを実装しない正当な理由は思いつきません。実際、私はそれを志願します！しかし、これについて大騒ぎする前に、私はlibastro / pyephemの専門家ではないことを知っているので、これが理にかなっていることを確認するためにこの質問を開こうと思いました. これが非常に正当な理由で行われた可能性は十分にあり、私はどうしようもなく混乱しています。

経験豊富なユーザーまたはソフトウェアのコアに精通している方からコメントをいただければ幸いです。

前もって感謝します！

pyephem ライブラリを拡張して、木星の CMLIII を計算できるようにするには、何が必要かを知っている天文学者はいますか? 現在のバージョンでは、CMLI と CMLII のみを計算します

ありがとう

特定の場所から、tle で定義された特定の衛星を追跡する基本的な Python スクリプトを作成しようとしています。私はアスト/軌道の人ではありませんが、より賢くなろうとしています。

私が使用しているさまざまなモデルが非常に異なる位置の答えを与えているという問題に直面しています。使用してみました: pyEphem spg4 predict (スクリプトからの exec システム コール)

私がテストしている衛星は、ISS と directv10 です (1 つは固定され、もう 1 つは移動しており、検証のためにインターネット追跡が利用可能です)。

予測ソースを変更して eci の場所を取得したので、それを使用して実際の場所を知ることができます。また、観測を検証するために使用する az、el、範囲も指定します。私は実際の場所を取得するためにspg4を使用しています。観測位置には PyEphem を使用しています。

私はspg4からECEFの位置を取得しています:

pyephem ベースの観察の私のコードは次のとおりです。

llh2ecef 変換:

aer2ecef:

(ecef の位置を使用して) 3D 地球上の位置を比較してプロットすると、いたるところで答えが得られます。eci 位置の予測 (ecef に変換) は、ISS 追跡 Web サイト ( http://www.n2yo.com/?s=25544 )で見たものと一致します。

get_real() の結果は、スケールと場所がかなりずれています。get_ob() の結果の縮尺は正しいが、地球上の位置が間違っている

結果の例:

予測ベース:

Python ベース:

az、el、および範囲は、2 つの観測値の間で一致しません。位置が「真の」位置と一致しません。(緯度と経度はありますが、高さは ecef2llh 変換後ではありません。

Web ベースのトラッカーと比較すると、予測される「真の」位置が Web サイトと一致していることに気付きました。directv10 の場合、pyEphem は方位角と仰角に一致しますが、ISS には一致しません。

それらを地球上にプロットすると、予測されたeciの「真の」場所が正しい場所にあります-トラッカーWebサイトと一致します）。spg84 ecef の位置 (predict と同じはずだと思っていましたが、地球の反対側にあります。predict の「観測された」位置は、spg84 の位置に近いです。pyEphem は高度が完全にずれており、表示されていません (あまりにも低い、地球の内側）。

私の質問は、python モデルをどこで間​​違って使用しているのかということです。私の理解では、spg84のpropagate()呼び出しは、衛星の実行位置をメートル単位で返す必要があります。私は、eci2efec 変換後の予測位置と一致する必要があると考えていたでしょう。また、sat.sublat、sat.sublong、sat.elevation を使用すると、llh2ecef() が一致することも期待していました。

私が言ったように、私は周回するすべてのものに慣れていないので、単純な数学の間違いか何かをしていると確信しています。私はグーグルで回答、例、チュートリアルを可能な限り検索しようとしましたが、これまでのところ何も役に立ちませんでした（これらのバグを解決するために複数の ecef2llh および llh2ecef メソッドを試しました.

正しい方向への提案、アドバイス、指針をいただければ幸いです。誰かの役に立てば、私が使用している完全なコードを投稿/送信できます。私はここに重要な部分を投稿したことを確認しようとしましたが、これを (すでに非常に) 長い投稿にしたくありませんでした。

助けてくれてありがとう。

アーロン

アップデート：

問題の少なくとも一部を見つけました。spg84.propagate() は、ECEF ではなく ECI で場所を返します。eci2ecef をすばやく実行すると、予測応答と完全に一致します。

助けを求めて投稿した後、私はいつも解決策を見つけるようです;）

次に、オブザーバーの位置で何が起こっているかを把握する必要があります。要するに: pyEphem.compute() から結果を取得し、衛星の ecef 位置を取得するにはどうすればよいですか? 緯度、経度、標高ではなく、az、el、範囲の値で行うことをお勧めします。

aer2ecef 呼び出しのバグを推測しています。

ありがとう。

更新 2:

「真の」位置と一致するように観測を取得しました。単位に問題があったようです。作業コード:

適切な位置を返すには aer2ecef() メソッドが必要です...

PyEphem を使用して太陽の緯度と経度を計算しようとしましたが、理解できないのは、太陽の経度と星座を計算するときです

43:02:58.8 は 13.02 おうし座ですが、星座を取得しようとすると

それは牡羊座と言っています何が間違っているのかわかりません誰か助けてください

Windows XP の Python 3.3.0 バージョンにephemパッケージをインストールしたいと考えています。

最初に、システム コマンド プロンプトからpip install ephemルートを試しました。Unable to find vcvarsall.batというエラー メッセージが表示され、プロセスが中止されました。

このような困難については、ネットで以前のアドバイスを読みました。それに続いて、自分のコンピューターにmingw32をインストールし、 C:\MinGW\binをPATH変数に追加し、 Lib / distutilsにdistutils.cfgという新しいファイルとコンテンツを提供しました。

インストール コマンド ( pip、 *easy_install* 、およびsetup.pyはすべて同じように機能します) を実行すると、次のエラーが発生します。

問題を理解し解決しようとしましたが、うまくいきませんでした。そのような値が確立されているコード内の場所を見つけることさえできませんでした。

¿誰か助けてくれませんか? ¿エフェムは、3.3.0 ドキュメントのPython モジュールのインストールで「すべての拡張機能を MinGW または Cygwin で構築できるわけではありませんが、多くは構築できます。」

前もって感謝します

パコ

基本的に私がやろうとしていることは次のとおりです。

• 観測点を取る (緯度/経度を使用)
• 開始日を指定して、次の春分と至点の日付を計算します
• それぞれの日没方位角を見つける
• それぞれの日の出方位角を求める

*注意してください、私はArcGISで作業しているため、私の値の一部は外部テーブルから取得されています

ここに私が持っているもののようなものがあります:

私は「next_setting」の部分でハングアップし続けています。私は NeverUpError を取得します...それを previous_setting、next_rising、previous_rising に切り替えても問題ありません。私は常に NeverUpError または AlwaysUpError を受け取ります。

誰かが春分の日の入りの方位角を見つけるのを手伝ってくれれば（任意の日付で）、残りを理解できると確信しています.

何か不明な点があればお知らせください。

ありがとう！

alt=0 (星の出/星の入り) にあるとき、星の方位角を計算する方法を理解できないようです。たとえば、シリウスとしましょう。

つまり、最終的には 2 つの値を持つことになります。

Sirius.az @ スターライズ Sirius.az @ スターセット

これは可能ですか？

ありがとう！