SonotaCo.JP

[SonotaCo]

UFOCapture利用報告会でお話しさせて頂いたUFORadiantですが、
なにしろ慣性が大きいソフトウエアになりそうです。

試作版はかなり動く所まで行っているのですが、
作ってみると、色々な問題点や可能性が見えて来るもので、
1月に作った試作版は一度捨てて、再度、腰を据えて開発しようと思いました。

で、将来のマニュアル代わりに、考えたこと、決めたことなどここにメモしていこうと思います。
ご意見、ご感想など、随時歓迎します。

何故、今、UFORadiantなのかというと、それは、限られた時間の中で、ゴールを目指すための作戦なのです。
UFORadiant無しにUFOAnalyzerやUFOOrbitの改良を行っても、それはきっとすぐ作り直すことになってしまいます。
おそらくは、UFOAnalyzerが抜本改良されたあかつきには、過去の全クリップを再分析するという作業が待っています。
過去に溜めたクリップから精度の良いデータが抽出できるわけで、必ずやると思います。
その作業はきっと、大変なものでしょう。それは一度で済ませたいと思うわけです。

本当は一気にオンラインデータベースを作ってしまえば良いのですが、現状では要素技術不足で、多分挫折してしまうでしょう。
千里の道も一歩からというわけで、何事もできることを一歩づつ進めると、無理と思えたこともいつの間にかできてしまったりします。
遠回りでもどかしい感じもするかもしれませんが、どうぞ、暖かく見守ってくださいね。

[SonotaCo]

[モチベーション]
高精度化と誤差算出を目標としてUFOAnalyzer,UFOOrbitを全面改訂する。
この際、末永く利用可能なデータ形式を定めて、これに準拠させたい。

[開発方針]
先ず、流星情報データベース MDBを定める
MDB管理プログラム例として輻射点管理ソフトUFORadiantを最初に作る

[考えないといけないこと]
1. MDBのデータ形式
2. UFORadiantの機能
3. UFORadiantの内部処理方法

[MDBの基本要件]
・過去の様々な流星データを一元的に管理、利用できる
・少なくとも今後20年分程度のデータを蓄積できる
・将来、オンラインデータベースとして運用可能
->Webサーバーに広く実装されているRDBで実現可能な範囲を超えない
->蓄積形式は固定幅の表の集合で表現する
・複数のまとめ方が共存できる
・多数の人のオフライン分散処理に対応できる
・誰でも、流星研究ができる
->個人用の小規模の専用プログラムで最初に実現する(これがUFORadiant)
->出力形式は一部XMLを用いるが、データ交換形式はCSVとする

[SonotaCo]

[MDB内の基本データ]
List : 輻射点リスト
Stream : ストリーム(群)データ
Orbit : 軌道データ
Radiant : 同時観測による輻射点計算結果(Orbit-Event間のN:N関係リンクでもある)
Event : 単点観測データ
Position : 同時観測によって求まったフレーム毎の流星位置
Direction : 単点観測によるフレーム毎の流星観測方向
Media : キャプチャされた静止画動画
Source : データソース (分散処理においてデータが重複しないようにするための処理者、由来などを示す番号)
Location,Camera,Lens,Digitizer,Software : 各要素の統一ID

[リンク類]
LSlink : List-Stream間のN:N関係
SOlink : Stream-Orbit間のN:N関係
OOlink : Orbit内の代表(平均値)-要素間関係

[考えたこと]
1. 誰でも、自分なりの集合関係を築くことができる(複数の交錯する関係が共存できる)ように リンクテーブルを用いて N:N関係を実現する
2. 完全なオンラインデータベースになる前は、多数の人がオフラインでどんどん情報を作っていき、これを結合する形態とならざるを得ない。
このため、作成されるデータにはユーザ固有のID(Source番号)を付加して、識別可能としておく。
マージの時に内容が同一なレコードを一本化する処理を行う。
IDが必要なものはリスト、ストリーム、軌道、イベントなど色々な種類のデータがあるが、
沢山の種類があると管理が煩雑なので、これらを全て1つの Source番号 で処理する。
Source番号は、MDB上で処理をして、新たなデータを追加する人が各々1つずつ採るものだが、
データの由来を示すわけで、IMOやNMSなどの過去の蓄積データもこの番号を1つずつ採るものとする。

[SonotaCo]

UFORadiantが扱う上位のテーブル案を作ってみました
群の活動開始、終了、極大は従来の月日によるものではなく、太陽黄経で記述しようと思いました。
この案で、プログラムの設計をしてみようかと思っています。

[上田昌良]

思いつくままに書いています。

位置測定精度ですが、
視野の中央付近にある恒星、視野の右の方にある恒星、左の恒星
を流星位置を測る方法で測り、その結果、求まった赤経・赤緯を
星表の恒星位置（赤経・赤緯）と較べてその差が位置測定精度と
してはいかがでしょう。

「天文・宇宙の辞典」恒星社、昭和５３年発行には、
方位角：方位角を測る起算点や向きは、それぞれの問題や応用の
便宜のため、いろいろな取り方をする。例えば、南を起算点とし、
東および西に北まで１８０°ずつ測るとか、あるいは、西まわり
に１周し３６０°まで測ったりする。よく用いられるのは、北点
から東まわりに１周３６０°測る方法である。」
とあります。起算点は北でも南でもその表示をしておけば、変換
もできますので、どちらでも問題ないと思います。
私は、北を起算点に１票を投じます。

[SonotaCo]

コメントありがとうございます。参考になります。 ＞　上田さん

精度の表現については、まだ細かく考えていませんが、
多分、認識恒星数 xx 個、平均位置誤差 x.xx度 位置誤差標準偏差 x.xx度 などと表現する方法が第一感です。でも、これだと手動計算するのが大変そうですね。最大誤差（あるいは標準誤差の3倍程度)を1つだけ出す方法が自動計算と手動計算との互換性があって良いかもしれませんね。検討してみます。

方位は次期UFOAnalyzerでは ご推薦のとおり、北原点、東回りにして、 用語もアジマス(Az) として統一しようと思っています。
仰角もAltitude は 地表高度(km) と用語が重なるので、エレベーションと呼ぶことにして、観測方位仰角は (Az, Ev) でいこうかと思っています。

なにせ、素人が設計してますので、用語等で改善した方が良い点などあれば、どんどんご指摘くださると助かります。

[SonotaCo]

UFORadiantのコーディングを進めています。
作らなければいけないものが結構本格的なデータベースだと分り、足元のデータ処理関数などに時間が掛かっています。気持ちとしては、メモリがある限りバッファを自動拡張して、データ数の上限をなくしたい とか、n対n リンクを通常のリレーショナルデータベースのようにサーチを主体とした処理ではなく、内部的には双方向リンクを使って高速化したい とか、色々欲が出て困っています。 プログラムというものは良いものにしようとするとキリがありません。どこまでが必要かを見切るのが一番大事で、難しいです。高望みしたり、急いだりすると全体が失敗してしまうこともあります。市販のデータベースソフト＋そのアプリケーション より高速で使いやすいものを作ろうという意気込みでやっています。先日の会合の後、一度スクラップにして作り直していますが、あと1週間ほどで前回のレベルには到達できそうです。しかしながら、公開できるのはいつになるかまだ見当がつきません。どうぞ、気長にお待ちください。 --- 殆ど独り言でした

[ts007]

着実に進んでいるようですね。こちらは、観測で頑張りたいと思っています。完成を楽しみにしています。

[SonotaCo]

進捗報告です。
ようやく、スクラップアンドビルドで、1月末の状況まで取り戻しました。
n対n対応をサーチ無しで処理できるようになり、1対nと同等の速度と使い勝手が実現できました。

で、軌道図(Orbit Map)なども組み込んでみたのですが、それで分ったことがあります。
複数の軌道の平均軌道を出してこれを代表にしようとしていたのですが、これがうまくいきません。
たとえ同じ日であっても、複数の観測結果の軌道要素を単純に平均すると、平均結果は地球とぶつからなくなってしまうのです。
考えてみれば当たり前ですが、各々の軌道はちゃんと地球とぶつかるものであっても、軌道要素を独立に平均すると、全然別の軌道になってしまうのです。方向や地心速度の所で平均して、それで地球と交わるように再度軌道計算しないといけないのだと思います。
と、いうわけで、やはり予想外に手強いです。

[SonotaCo]

先日の会合では、皆さんから色々な資料を頂きました。
「まだUFORadiantのD'判定にはバグがあって......」
という話しをしたら、あっという間にD’判定の資料のコピーが私の机の上にありました 有難くて、涙がでます。

で、今日、その資料が役立ちました。資料に沿ってプログラミングした所、ほぼ似たような軌道を集めて表示できる所まできました。
D'判定が動きはじめると、凄く面白いです。
最初、日付範囲も考慮するようにプログラミングしたんですが、試しにとD'判定だけで年間の軌道の中から似たものを選ぶようにしたところ、ra-dec-vg による判定では到底検出できないような類似軌道が出てきます。
物凄く日付の離れたものや、方向が全然違うものなどもでます。
以前ならバグと思う所ですが、軌道図が描けるようになっているので、それで見比べた所、似ているんです。
軌道傾斜角が小さい流星では、よく似た軌道でもわずかな差で地球軌道と交わる日が大きくかわるのが原因です。これも当日上田さんからご指摘頂きましたが、まさにそのとおりでした。おもわず、おーー と見とれました。
D'判定のような論理を使えば流星の自動クラスター分類もできそうです。群と見なしてよい集中が発生したことを自動検出することもやればできると思います。あ、、また変な夢を見てしまいました 。

[SonotaCo]

せっかく、軌道表示機能があるので、各流星群の代表軌道も表示できるようにしたいと思いました。
ゆくゆくは、観測データから作った各群の代表軌道を表示すべきなのですが.....
で、とりあえず、輻射点リストにある ra,decと速度(V∞)から、その軌道を逆算するプログラムを作ってみました。
Vg ...地球の引力を受ける前の流星の速度(地心速度)
Vi ...大気抵抗減速を受ける前の流星の大気圏外速度
Vo ...実際の観測される流星の速度(観測速度)
Vg→天頂引力と日周光行差→Vi→大気抵抗減速→Vo
これまでの輻射点リストの輻射点座標は修正輻射点、速度は Vi
なので、Vi からVgを出して、これで軌道計算するわけです。
これも、楽しい機能になりそうです 。例えば今のリストにある2月の流星群の代表軌道を描いてみると以下のようになりました。
いろいろ、遊んでしまって、なかなか前にすすまず、すみません
まだUFORadiantとしてやりたいことが沢山未作成で、バグも野放し状態です。
使って頂ける方が果たして日本に何人おられるかと、ちょっと苦笑い状態ですが 、どうぞご期待ください。

[SonotaCo]

東京は天気がさっぱりで、プログラミングが進んでしまいます
昨日から、高速化に取り組みました。
5000個の軌道のリスト表示に5秒ほどかかるのがどうにも許せなくて、普段使わないVertual Listという技を使ってみました。
とたん、リスト表示の時間は皆無に近くなり、5000個の中から指定した条件で軌道を探す作業が、瞬時になりました 。
さすがに、数千個の楕円軌道を全部描画させると数秒かかりますが、ま、そんなに書いたら画像が見えなくなるだけなので、数十個程度を選択して描くならこれも殆ど瞬時です。...... なんか、いい感じです 扱える軌道数の上限はプログラム的には無く、メモリ容量と処理時間で実用上の上限が決まる仕様のプログラムですが、RDBなどを使うより圧倒的に高速で、軽く出来たようです。

[ts007]

埼玉も観測できていません。１１日から１３日まで熱を出してしまい、先週は、辛い１週間でした。今週は、やっと回復しましたが、今度は、晴れてくれません。瞬時に検索できるとのことで、どんな感じになっているのか興味津々です。

[SonotaCo]

なんとも散々な天気が続いてますね。
こういう時はプログラムが進むかと思いきや、最近はそうではありませんでした。
原因は3つ、
1つは画面デザインです。
元々ノートパソコンでも利用可能なようにと、1024*768のディスプレイでも利用可能なように設計しているわけですが、
これがネックで、同時に使える機能が限定されます。目的別に別ページを作れば個々はわかりやすくなるのですが、似て非なる機能が重複することになり逆に全体は分りにくくなります。
このために、新しいページを作ってみてはやっぱり止めるという試行錯誤が続きました。機能の整理は本当に難しいです。

2つ目の原因は、実際の作業手順の予想が付かないことです。観測結果に基づく群情報の作成と更新という大きな作業目的は決まっているのですが、具体的にどういう作業をしていったらそれが出来るかが、よく分らないのです。
つまりどんな機能を用意したら使いやすく便利かということが、実際の機能を作ってみて、使ってみないと見当が付かないのです。

3つ目は、どうやれば輻射点移動量が自動算出できるかという点です。


でも、なんとか山場を越えた感じです。
画面の整理は、右クリックや表の列名をクリックによるボップアップメニューなどの採用で、随分すっきりしました。
オマケですが、表を各項目をキーとしてソートできる機能まで付いてしまいました。
黄経順に並べたいとか、名前順にしたいとかのソーティングが一瞬でできるようになりました。

古いリストを参考にして新しいリストを作るには以下のような手順でできそうなメドが立ちました。
1. 参考輻射点を古いリストから選ぶ
2. D'判定でそれに近い過去の観測結果をリストアップする。
3. 綺麗に集まる(D'=0.05程度)まで観測結果を絞りこみ中心を出す。
4. 3をリファレンスとしてD'判定条件をD'=0.1程度まで緩め、多数の結果が入るようにして、これから輻射点移動量を定める。

輻射点移動量算出方法は色々試したのですが、結局比較的単純な黄経差を重みとした赤経差と赤緯差の平均が安定してもっともらしい値が出るのでそうしました。

今後は新輻射点リストを作成するテストなどをしてその間に発生する問題を解決すれば一段落になります。

[ts007]

色別になっていて見やすいですね。とてもすっきりしていて使いやすそうです。あと少しのようですね。頑張ってください。私は、１昨日から調子が悪く、昨晩も０時から天気が良くなったようですが、熱が出て観測できませんでした。今日は、何とかできそうですが天気が持ってくれればと思います。どうも体調管理がうまくいきません。そろそろ花粉にも悩まされます。