pixcelあたりのscaleを記述してあるのは、うちでは、
CDELT1 = -7.55731284340E-003 / [deg/pixel] X-axis plate scale
でした。
これは、文字列で記録されている+単位が度ですので、floatで数字にして、絶対値を取って、*3600をかけました。
で、Icでの測光に対応するために、例によって、Ic≒V-'B-V'でごまかすために、identify_sql.pyでvmagとなっているところ、2行計3箇所を(vmag- bv)に変えました。
例によって、結果を収納するtableでは、vmag表示のままにして有ります。
#バグを増やす可能性を減らしたい+面倒なので。
まぁ、画像の情報を格納したデータの方には、測光バンドが記録されています。
さて、VIEWの使い方覚えないと。
特定の星について集計したVIEWをつくりたいので。
#おや、また、新天体検出は先送りか？
わたしは、RDBは苦手です。
最大の原因は、table毎の相互参照を担保するためにユニークなキーが無いといけないことです。
で、Mhhさんのスクリプトを見て、MySQLに照会して、画像毎にユニークな番号を振る手を知ったので、画像をmicroarray slideに置き換えて、懸案の仕事用のデータベースも作らないと。
あ、array slide毎にuidを振ればいいのかな？実験ごとの管理は、同じように、日付で管理？？
pyFitsみたいな、データファイルのヘッダを見て、測定条件を取得するスクリプトを書くのがめんどいな。BioCondoctorにないのかな？
(追記)
まだ、Ic用のスクリプトは(わたしが直したところに)bugがいそうです。
ゼロ点決めるのにいくつの星を使ったかをみると、少なすぎます。
(追記2)
なんか複雑なVIEWをつくるより、pythonなりRなりで、データ抜き出して計算の方が早い気がしてきました。
(追記3)
Rでデータを読み出すときは、静的なSELECT文しか書けないみたい？
データを全部読み込んでから、R上で、選択しなおせばいいのですが、データが大きいと、しんどいです。
でも、今考えているような特定のの星についてデータ一覧が欲しいといた目的なら、まだ、大丈夫？
#いや、現在、Instrumental magとzero pointが別々のテーブルで管理されてるので面倒なだけで、同じテーブルに保存すれば解決。いや、それは、RDBぽくないや(w
それより、Stdに落としこんでから、DBVS2000で処理したほうが早い(w
