社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

膨大な天体データを効率的に検索する方法の考察と実装
田中 昌宏†

白崎 裕治†

大石

雅寿†

純平 ††

町田 吉弘††

坂本

道人††† 中本

堤

水本

好彦†

石原 康秀††

啓之††† 小林 佑介†††† 国立天文台†† 富士通（ 株）††† (株) セック
E-mail: †masahiro.tanaka@nao.ac.jp
あらまし

我々は、世界中の天文台が観測したデータを配信するための統一的な規格を策定し 、その規格に基づく天文データ配信システムであるヴァーチャル天文台の構築を進めている。これが普及すれば 、誰でも膨大な量の天体デー
タに容易にアクセスできるようになるが、その膨大なデータの中から必要なデータを見つけ出すことは容易ではない。
そこで我々は、あらゆる天体データについて、その情報の一部をキャッシュすることにより、膨大な天体データを効率的に検索するシステムを開発した。この際に用いた、天文用途における効率的な検索方法とデータベース構造について考察する。
キーワード

科学 DB, 天文 DB

Implementation of an Eﬃcient Search Method for Large Astronomical
Databases
Masahiro TANAKA † , Yuji SHIRASAKI † , Masatoshi OHISHI † , Yoshihiko MIZUMOTO† ,Yasuhide ISHIHARA †† , Jumpei TSUTSUMI †† , Yoshihiro MACHIDA †† , Michito SAKAMOTO†††, Hiroyuki NAKAMOTO ††† , and Yuusuke KOBAYASHI †††† National Astronomical Observatory of Japan†† Fujitsu Ltd.
††† SEC Co. Ltd.
E-mail: †masahiro.tanaka@nao.ac.jp

Abstract We have developed a Virtual Observatory (VO) system, aiming at easy access to astronomical data in
the world. In this activity, we have deﬁned international standard protocols to access astronomical data, and implemented a system based on those protocols. However, the VO architecture does not always alleviate ineﬃciencies inretrieving all the available information on a certain astronomical object. We thus developed a new eﬃcient searchsystem by caching all the available astronomical data to our uniﬁed database. We discuss a fast search method andthe architecture of the uniﬁed astronomical database including billions of celestial objects.
Key words Science DB, Astronomical DB

1. は じ め にと呼ばれるプロジェクトが各国で進められている。VO とは 、観測により蓄積された膨大な量の天体データの中から容易に世界中の天文台では日々観測を行っており、データは蓄積さデータを発見できるような仕組みを、情報処理技術によって実れ続けている。その上、天文観測装置も進化し続けており、それ現する取り組みである。世界中の天文データを共通に利用できによって発生するデータの量も増え続けている。こうして蓄えるようにするため、各国の VO プロジェクトが IVOA [1] におられたデータを有効活用するため、Virtual Observatory (VO)

いて連携し 、天文データ配信についての統一的な規格を策定し—1—てきた。その成果には次のようなものがある。天文データサー
ビスの発見を容易にするため、天文メータデータの標準仕様を

XML 形式で定義し 、そのメタデータを OAH-PMH を用いて配信するという標準仕様が取り決められた。また、天体データを格納するフォーマットとして、従来から存在する FITS デー
タフォーマットの他に、VOTable という XML によるテーブル
データの仕様が策定された。その他、画像データ配信プロトコルとして SIAP 、天体データベースを検索するための SQL を基づく天文検索言語 ADQL [2] といった仕様が策定された。
日本では、Japanese Virtual Observatory (JVO) [3] というプロジェクトを我々が進めている。JVO では、SQL に基づく
天文検索言語を開発した。これが IVOA における標準天文検
索言語の基になった。また、VO へのアクセスを簡単な操作で行うための Web アプ リケーションである JVO ポータルシス
テム [4] [5] を開発した。このポータルは現在公開 [6] しており、一般ユーザも利用できるようにしている。

2. 統合天体データベース
この VO が天文研究にとって実際にに役に立つかど うかは 、
実際の天文研究における VO の利用方法について考える必要

図1

統合天体データベースによる検索効率の向上

Fig. 1 Eﬃcient Query with Uniﬁed Astronomical DBがある。天文では観測データというわずかな手がかりから天文現象の本質を理解することが求められる。そこで、近年の天文的に検索する手法を考察した。以下ではこの手法によるデータ

研究では、銀河や星など 、ある天体について詳しく研究する場

ベースの設計について述べる。

合、電波・赤外線・可視光・紫外線・X 線・ガンマ線という多くの波長のデータを組み合わせることが必要になってきている。
また、変光星や超新星、ガンマ線バーストなど 、明るさの変化が重要な場合には、時間をおいた複数の観測データが必要とな

3. 天球面インデクスによるテーブルパーティショ
ニング
統合天体データベースの構築にはリレーショナルデータベーる。このように、異なる観測装置によるデータが天文研究にはスシステムを利用するが 、登録する天体数が多いため、検索性不可欠であり、このとき多くのデータを効率的に集めるために能が問題となる。大規模な天体カタログの例として、2MASS [7]VO を用いることが想定される。

全天カタログは約 5 億、SDSS DR6 [8] カタログは約 3 億もの一方、VO によって公開される天文データは、すばるのデー

天体のデータを含んでいる。このように 、少なくとも 10 億天

タは国立天文台、ハッブル宇宙望遠鏡のデ ータはア メリカの体のデータを瞬時に検索できるデータベースが必要である。そSpace Telescope Science Institute というように、それぞれ観こで、レコード 数が多いデータベースを効率的に検索するため測を行った研究機関により配信されることが多く、別々のサーの手法として、テーブルパーティショニングを用いた。

ビスとして提供される。そのため、どのサービスに目的の天体

天文検索では 、天球座標による検索が基本であることから 、が含まれているかわからない場合には、それらのサービスすべ

天球座標によるテーブルパーティショニングをおこなった。天てについて検索しなければすべてのデータを得られない。しか球座標のインデクス化の手法として、HTM (Hierarchical Tri-しこの手法は次に述べるように非効率である。第一に、すべて

angular Mesh) [9] [10] と HEALPix [11] の 2 種類の方式が提案の天体データ配信サービ スにクエリを送信しなければならなされている。我々は利用実績のある HTM を採用した。

い。第二に、全天くまなく観測した例はわずかであり、多くのHTM による天球面の分割の概念図を図 2 に示す。HTM で場合は天の一部の領域しか観測していないため、問い合わせたは 、まず天球面を x-y, y-z, z-x 軸をそれぞれ含む大円で 8 分

サービスに目的の天体が含まていれる確率は小さい。この様子割する。それぞれの領域は 3 つの大円を辺に持つ球面三角形でを模式的に図 1 (上) に示す。このように、VO が普及し多くのあり、北側は N0, N1, N2, N3 、南側は S0, S1, S2, S3 というデータ配信サービスが立ち上がっただけでは、ある天体につい

インデックスをつける。それらのうちの 1 つの球面三角形に着て多くの観測データを効率的に集めたいという天文研究者の要目して、3 辺の中点を結ぶ線で区切ると、さらに 4 つの球面三望がかなうわけではない。

角形の領域に分割できる。S0 の領域を分割してできた 4 つのそこで、我々は、Web 検索サイトがあらゆるサイトのページ

領域には 、S00, S01, S02, S03 というインデックスをつける。

を収集して効率的に検索ができることにならい、天体データに同様のことを繰り返すことにより、さらに細かい領域へと分割

ついても、配信されている天体データを集めて「統合天体デー

することができる。このように球面三角形の 4 分割を繰り返

タベース」(図 1 下) を構築し 、このデータベースに対して効率—2—の範囲がわかれば 、パーティショニングテーブルに対する検索
条件は、サブクエリを用いて次のように記述できる。

select ra, dec, j_mfrom ( select * from psc_63488 where
htm_id between 0 and 65535
union select * from psc_63488 where
htm_id between 217088 and 218111
union select * from psc_47104 where
htm_id between 0 and 65535...
) psc;
こちらの構文は標準 SQL に基づいているから、そのまま RDBに送信できる。この座標範囲構文を置換するプログラムは Javaで実装した。ところで、この HTM 範囲条件だけでは厳密には円の領域を表すものではないため、さらに領域の境界条件を加える必要がある。
図 2 HTM による天球面の分割

4. 提案手法による検索効率の測定

Fig. 2 Splitting the Celestial Sphere by HTM

前節で述べた手法による検索性能を測定し た。測定の際にすことにより、天球面上の領域を分割し インデクス化する手法

2MASS カタログの全 5 億天体のデ ータを用いた。利用し たが 、HTM である。最初の 8 分割をレベル 0 と呼び 、次の 4 分

RDBMS は PostgreSQL version 8.2 、OS は Linux 、用いたマ割はレベル 1 と呼ぶ。したがって、レベル N では 、天球面をシンの CPU は Pentium-4 2.8 GHz 、メモリーは 2 GHz であ8×4

る。検索に要した時間を、検索範囲を変えて測定した結果を表N

分割することになる。1 回の分割は 4 であるから、これを 4 進数とみなせば 10 進整数に対応づけることができる。こ1 の「独自方式」の項目に示す。この経過時間には、天球座標かのとき、最上位ビットを常に 1 にしておき、レベル 0 では、N0

ら HTM インデクスへの条件変換にかかる時間 (0.5 秒以下) はは 8 、N1 は 9 、... 、S9 は 15 とする。レベル 1 では、N00 は含まれていない。測定の結果、検索半径が 1 分角という天体近16 、... 、S33 は 63 とする。こうすることにより、数値から分傍の検索では 、0.04 秒と瞬時で済むことがわかった。さらに 、割レベルを判別できる。

半径 180 分=3 度、天体数で約 6 万という、天文においては広HTM のレベルを決めれば 、与えられた天体の座標が属する

い範囲の検索についても、1 秒以下という比較的短時間で検索

HTM インデックスが決まる。レベルが大きいほど 位置の精度できることがわかった。このように、我々の手法は大規模な天が良くなるが 、桁が大きくなってし まう。ここでは 、0.3 秒角

文データベースにおいても十分な性能を持つことがわかった。

の精度に相当するレベル 20 を採用する。

ところで、PostgreSQL には、version 8.1 よりパーティショ

天体データを DB のテーブルに格納する際、この HTM イン

ニング機能が導入されている。この機能を用いることにより、デックスによりパーティショニングを行った。今回は、天球全パーティショニングテーブルをあたかも１つのテーブルのよう体をレベル 6 、すなわち 8 × 46 = 32768 で分割し 、その領域に SQL を書くことが可能であり、前節のようなサブクエリを用ごとにテーブルを分けた。分割したテーブル名は、psc 32768,

いる必要がなくなる。そこで、このパーティショニング機能がpsc 32769, ... , psc 65535 とした。これらのテーブルに対し利用できるかど うか検証するため、両者の性能の比較を行った。

て座標による検索を行うには、座標の範囲条件から HTM の範ところが 、前節と同様にテーブルを分割した上で PostgreSQL

囲条件に変換する必要がある。VO では 、検索条件の記述に 、のパーティショニング機能を用いると、検索ができないことがSQL を拡張した天文検索言語 ADQL [2] を用いる。ADQL でわかった。理由は、テーブル数が多すぎるため、検索の際に多は座標検索を次のように記述する。

くの shared memory を必要とし 、不足するからである。我々の環境では、テーブル数を 16 分の 1 にすると動作するようになっselect ra, dec, j_mfrom psc where Region(’Circle 0 0 1’);たため、その条件で測定した。結果を表 1 の「 PostgreSQL 」の項目に示す。その結果、検索半径 1 分角でも 6 秒、半径 1 度でここで Region(’Circle 0 0 1’) は ADQL 拡張構文であり、は 9 秒と、1 回の検索でもしばらく待たされるという結果となっ天体の座標が赤経 0 度赤緯 0 度半径 1 分角以内であるという条た。しかも、検索半径と検索時間が相関していない。表 1 には件を表す。この座標範囲に対応する HTM の範囲がわかれば 、

where 句に含まれる HTM 範囲条件の数も示しているが 、検索

どのテーブルを検索すべきかがわかる。この HTM 範囲の計算

時間はむしろその HTM 条件数と相関しているように見える。

には、HTM 開発者による Java ライブラリを利用した。HTM

これらの結果から、理由は不明だが 、現時点の PostgreSQL の—3—

表 1 パーティショニング性能測定結果

表 2 統合天体データベースのカラム設計

Table 1 Performance of Partitioning Table

Table 2 Columns in the Uniﬁed Astronomical DB

検索
半径
分角

経過時間 (秒)

天体数
個

独自

1

2

方式
0.04

10

165

0.03

Postgre

HTM 条件数
独自

PostgreSQL
方式 1
6.46 154
32

SQL2
32

3.81 127

比

16

60

6697

0.11

6.47

60

32

32

26720

0.31

2.02

7

16

4

57246

0.71

9.04

13

72

columndescription

Objectid

Object ID

name

Object namera

Right Ascension

Position

16

100
180

category48

Fluxの場合、1 行が 1 天体に対応し 、1 天体について多くの種類のデータがカラムとして並べらられる。そのデータのうち主なものは、座標 (赤道座標) 、明るさ (可視光では主に等級) 、およびそれらの誤差である。明るさのデータとして、B バンド (青) 、V バンド (緑) 、R バンド (赤) 、I バンド (赤外) など 、いくつかの波長について記載されることが多い。その他のデータとして、銀河であれば視直径や赤方偏移 (地球から遠ざかる速度の指標であり距離の指標になる) などのデータが加えられることもある。このように、カラムの種類は天体カタログによって様々である。こうした多種多様な天体カタログを、そのまま 1
つのテーブルにすることは困難である。明るさのカラムだけでX 線から電波まで数え切れないほどの種類があり、特殊な波長で観測される場合もある。そこで、従来の 1 行に 1 天体の情報を含む形式ではなく、1 行に 1 つの明るさのデータを含むようなテーブル設計とした。このようなテーブル形式を持つ例として、論文に掲載された赤外線観測データをまとめた Catalog ofInfrared Observation [12] という天体カタログがある。
このような設計にした場合の問題は、上で述べたような明るさ以外の様々なデータをど う扱うかということである。ここでこの統合天体データベースの目的を考えると、様々な天体カタ
ログをキャッシュして高速な範囲検索を実現することであった。
したがってデータベースを複雑化してすべてのデータを取り込
むことはせず、座標や明るさなどの基本的な情報のみを保持することとした。一方で、元の天体カタログに存在し 、統合天体
データベースに含まれないデータが必要な場合もある。そこ
で、統合天体データベースには元のデータを配信しているサービスへのリンク情報を保持し 、必要であればその情報を基に元のサービスにアクセスすることにより、すべての情報を引き出すことが可能になる。
このような方針に基づき、設計したテーブルのカラムのリス

HTM index

flux

Flux value in catalog

flux err

Flux error

flux srch Flux in Jy
Reference

5. テーブルの設計
次に統合天体データベースのテーブル設計について述べる。

htm

flux unit Unit of ﬂux

述べたような独自の実装で構築することとした。

一般的な天体カタログはテーブル形式のデータである。多く

Position Errorband unit Unit of band

パーティショニング機能は検索性能を十分には発揮できていな
いようである。このため、「 統合天体データベース」は前節でDeclination

pos err

Wavelength band name Band name

1: union でつなげたサブクエリ条件数2: where 句中における between でつなげた HTM 条件数

declink refLink URL to referenceorg idID in original catalog

cat idCatalog IDa ) Object カラム
カラム id はこの統合天体カタログにおいて一意な ID 番号であり、カラム name はこの天体の名称である。

b ) Position カラム
天体カタログには必ず天体の座標が記載されているが 、その座標系にはいくつか種類がある。統合天体カタログでは、現在一般的に用いられる 2000 年分点の赤道座標系に統一し 、カラム ra に赤経、カラム dec に赤緯を格納する。単位は度とする。
天体の位置の精度は観測装置や観測条件により異なるため、位置の精度をカラム pos err に格納する。この位置の精度は、東
西南北の方向によって異なる場合があり、誤差を形にすると円でなく楕円であったり他の形であったりする。ここでは単純化のため 、最大の誤差を使用することとする。カラム htm には

HTM インデクスを格納する。
c ) Wavelength カラム
天体の明るさは、特に可視光・赤外線では、ある波長範囲だけ透過するフィルターを通して測定されることが多い。よく用いられる標準的な波長帯 (バンド ) には、V バンドというように名前がつけられている。統合天体データベースのテーブルには、
カラム band name を設け、天体の明るさを測定したバンド 名をここに格納する。明るさを測定した波長帯が一般的なバンド でない場合や、波長が記されている場合などは、その中心波長をband name に格納する。その場合、波長の単位を band unit に格納する。
この波長情報のカラムを含むことが 、通常の天体カタログと大きく異なる部分である。通常の天体カタログでは、1 つの明
るさのカラムは同じバンド で測定されたものであるから、波長のカラムを必要としない。

d ) Flux カラム
明るさのデータはカラム flux に格納する。明るさにはさま
ざ まな単位がある。可視光では等級の単位が主流である。その他の波長域ではエネルギーの単位などが用いられる。その単位

トを表 2 に示す。以下にこれらのカラムについて説明する。

—4—

をカラム flux unit に格納する。また、明るさの誤差をカラム

flux err に与える。
天体の明るさを比較する場合は、同じ単位系にする必要がある。そこで、天体データをデータベースに格納する際に、天文において標準的な明るさの単位であるジャンスキー (Jy) に変換し 、flux srch カラムに格納する。これにより明るさの単位が異なっても比較できるようにする。ただし 、バンドが違った
り、同じバンド でも透過特性が異なる場合などは、明るさを正しく比較できない可能性がある。flux srch カラムは、あくまで目安として使用し 、利用者は収集したデータから総合的に判断すべきである。

e ) Reference カラム
cat id カラムは出典の天体カタログを表す ID である。この図3

天体検索インタフェース

Fig. 3 Query Interface for the Uniﬁed Astronomical DB

ID には、IVOA で策定された識別子の仕様に則ったものを用いる。org id カラムは出典カタログ内における ID である。たいていの天体カタログには、その天体ごとにの ID 番号あるいは記号が付与されており、これによって同一天体についてのデー
タであることを判別する。link ref カラムはリンク情報を示
し 、データを提供するサービ スへの URL である。これら３つの情報に基づいて元のサービスへアクセスすることにより、元のカタログから詳細な情報を取得することが可能になる。

6. ユーザインタフェース
この統合天体データベースは、現在 2MASS など 一部のデー

図 4 検索結果表示画面

タを登録して JVO ポータル [6] から利用できるようにしていFig. 4 Result table Browser

る。ユーザインタフェースは図 3 のようにシンプルであり、検索結果は図 4 に示す機能豊富なテーブルブラウザから閲覧することができる。今後は順次データを増やしてゆき、VO から利用できるほとんどのデータを登録する計画である。

7. 今後の課題
7. 1 テーブルの正規化が必要となる。
その他に、テーブル変換の自動化も必要になる。天体カタロ
グのデータを統合天体データベースに追加する際、前述のように両者のテーブルの形式が異なることから 、天体カタログから座標や明るさのデータを探してテーブルを再構築する必要がある。ここに VO の成果が利用できる。IVOA では 、UCD

今回設計したテーブルは、出典のカタログを外部の情報とリ(Uniﬁed Content Descriptors) と呼ばれるデータの意味を表す

ンクすることにより、冗長性を減らしている。その他に 、1 つための語彙のセットが定義されている。VO で配信される天体の天体に対して複数の明るさのデータが存在するという冗長性

カタログには、この UCD によるカラムの意味づけが行われてが残っており、理論的には正規化が可能である。今回は、デーいる。したがって 、VO を通じて得られたデータについては 、

タベースの管理が煩雑にになると予想されるため、さらなる正統合天体データベースに格納するデータ項目を、UCD から自規化は行わないこととした。

動判別することが可能である。

7. 2 統合天体データベースの管理

以上のような自動処理方法を実装することにより、あらゆる

今後、統合天体データベースへデータを追加・削除するといっ

天体データを格納することが実現できれば 、統合天体データ

た管理が必要になるが 、膨大な量のデータを管理することは容

ベースは天文研究にとって非常に有益なものとなるはずである。

易ではない。VO の世界には非常に多くの種類のデータが配信されるため、手作業ですべてのデータを追加することは不可能である。そのため、データ管理の自動化が必須となる。

8. ま と め
天文学研究において VO サービ スを利用する際の効率の問公開される天体カタログは、通例では一部が頻繁に書き換え

題から考えた統合天体データベース、およびその実現のためにられるようなものではない。新しいバージョンが出るとしても、開発した効率的な検索手法とテーブル設計について述べた。実丸ごと新たにリリースされる場合がほとんどである。したがっ装したデータベースは 、一部のデータを登録して JVO ポータて、データの更新の単位は、その天体カタログごと行うことをル [6] のサービ スとして公開しており、一般ユーザでも利用で考えればよい。つまり、天体カタログの単位で、追加・削除がきる。今後このデータベースに登録するデータを拡充する予定

できればよい。そのような作業が容易に行えるインタフェース

—5—

である。
文

献

[1] International Virtual Observatory Alliance. http://www.
ivoa.net/.
[2] N. Yasuda, Y. Mizumoto, M. Ohishi, W. O’Mullane, T. Budavári, V. Haridas, N. Li, T. Malik, A. S. Szalay, M. Hill,
T. Linde, B. Mann, and C. G. Page. Astronomical Data
Query Language: Simple Query Protocol for the Virtual
Observatory. In F. Ochsenbein, M. G. Allen, and D. Egret,editors, Astronomical Data Analysis Software and Systems(ADASS) XIII, Vol. 314 of Astronomical Society of the Paciﬁc Conference Series, p. 293, July 2004.
[3] M. Ohishi, Y. Shirasaki, M. Tanaka, S. Honda, N. Yasuda,
Y. Masunaga, Y. Ishihara, J. Tsutsumi, H. Nakamoto, andY. Kobayashi. Development of Japanese Virtual Observatory (JVO) : Experience on Interoperation with other
Virtual Observatories and its Future Plan. In C. Gabriel,
C. Arviset, D. Ponz, and S. Enrique, editors, Astronomical
Data Analysis Software and Systems XV, Vol. 351 of Astronomical Society of the Paciﬁc Conference Series, p. 375,
July 2006.
[4] Y. Shirasaki, M. Tanaka, S. Honda, S. Kawanomoto, N. Yasuda, Y. Masunaga, Y. Ishihara, J. Tsutsumi, H. Nakamoto,and Y. Kobayashi. Japanese Virtual Observatory (JVO):
implementation of VO standard protocols. In C. Gabriel,
C. Arviset, D. Ponz, and S. Enrique, editors, Astronomical
Data Analysis Software and Systems XV, Vol. 351 of Astronomical Society of the Paciﬁc Conference Series, p. 456,
July 2006.
[5] 田中昌宏, 白崎裕治, 本田敏志, 大石雅寿, 水本好彦, 安田直樹,
増永良文. バーチャル天文台 JVO プロトタイプシステムの開発. 日本データベース学会 Letters, Vol. 3, No. 1, pp. 81–84,
2004.
[6] JVO portal. http://jvo.nao.ac.jp/portal/.
[7] M. F. Skrutskie, R. M. Cutri, R. Stiening, M. D. Weinberg,
S. Schneider, J. M. Carpenter, C. Beichman, R. Capps,
T. Chester, J. Elias, J. Huchra, J. Liebert, C. Lonsdale,
D. G. Monet, S. Price, P. Seitzer, T. Jarrett, J. D. Kirkpatrick, J. E. Gizis, E. Howard, T. Evans, J. Fowler,
L. Fullmer, R. Hurt, R. Light, E. L. Kopan, K. A. Marsh,
H. L. McCallon, R. Tam, S. Van Dyk, and S. Wheelock.
The Two Micron All Sky Survey (2MASS). Astronomical
Journal, Vol. 131, pp. 1163–1183, February 2006.
[8] J. K. Adelman-McCarthy and for the SDSS Collaboration.
The Sixth Data Release of the Sloan Digital Sky Survey.
ArXiv e-prints, Vol. 707, , July 2007.
[9] P. Z. Kunszt, A. S. Szalay, I. Csabai, and A. R. Thakar.
The Indexing of the SDSS Science Archive. In N. Manset,
C. Veillet, and D. Crabtree, editors, Astronomical Data
Analysis Software and Systems IX, Vol. 216 of Astronomical
Society of the Paciﬁc Conference Series, p. 141, 2000.
[10] Hierarchical Triangular Mesh. http://www.sdss.jhu.edu/
htm/.
[11] K. M. Górski, E. Hivon, A. J. Banday, B. D. Wandelt,
F. K. Hansen, M. Reinecke, and M. Bartelmann. HEALPix:
A Framework for High-Resolution Discretization and Fast
Analysis of Data Distributed on the Sphere. AstrophysicalJournal, Vol. 622, pp. 759–771, April 2005.
[12] D. Y. Gezari, P. S. Pitts, and M. Schmitz. Catalog of Infrared Observations, Edition 5, July 1999.

—6—