OpenStreetMapプロジェクトが米国政府の地図データをインポート
OSMにデータをインポートする従来の手法の概要は、同プロジェクトのWikiに次のように記されている。個々のユーザはGPS軌跡を収集し、その軌跡データをOSM形式に変換し、各オブジェクトにラベルを付与してからその結果をOSMデータベースにアップロードする。地図の画像そのものは、必要に応じて別途レンダリングされる。
2004年のOSMの活動開始以来、提供されたデータの大部分は西ヨーロッパのものである。このことはOSMの地図サイトにある世界全図からもわかる。
いくつかの要因の組み合わせから、米国ではデータのマッピングがあまり進んでいない。まず、OSMを創設した人々はヨーロッパ在住だったため、当初の参加者数はヨーロッパが比較的多かった。また、英国のようなきわめて人口密度の高い国々では、使われる労力が同じであっても人口密度の低い国々よりずっと広い領域をマッピングすることができる。さらに、米国の場合は質の高い包括的なパブリックドメイン（社会の共有財産）の地図データがすでに存在するため、GPS軌跡によるデータ収集方法はボランティアたちにとってあまり魅力がない。
その地図データというのは、米国勢調査局のTIGER（Topologically Integrated Geographic Encoding and Referencing）システムのことである。国勢調査局は、10年ごとに実施する国勢調査など、自分たちのさまざまな活動を支援するためにTIGERデータベースを管理している。構築に公的資金が使われているという理由で、TIGERデータベースは法律によって共有財産化されている。
TIGERは、米国内のほぼすべての道路、幹線道路、鉄道、水域、法的管轄区域を網羅している。この地図データベースは、米国の地質調査および国勢調査の各地図の原本を組み合わせて作られ、国勢調査局の職員が現地で収集したデータによって更新されている。完全とはいえないが、米国全土を詳細部分までカバーしている。
前回の失敗
TIGERのデータは長い間、OSMにとって魅力的な対象だった。パブリックドメインであるため、大半の商用地図のようにライセンス供与による利用上の制約を受けることがない。また、ベクター形式で電子的に入手できるため、適切な変換ユーティリティさえあればOSMの形式への自動変換が可能である。
TIGERデータの大量インポートは2005年に試行されたが、最初の数回の試みで質の高い結果の生成に失敗したことでこの活動は中止された。しかし、2007年の春になってBrandon Martin-AndersonとDave Hansenの両氏が新たな取り組みに着手し、以前の変換およびインポート用コードのバグ取りとインポートのやり直しを行っている。
以前TIGERの構文解析コードを書いた経験があるMartin-Anderson氏は、ほかのOSM開発者の助けを借りて、このコードをTIGERからOSMへのデータ変換スクリプトに仕上げた。時間がかかるのは各種の属性を2つの形式の間でマッピングする部分だった、と彼は言う。「関係者としては、どれほど多様なTIGER用タグがOSM用タグに変換されているかについて言いたいことがたくさんある。たとえば、TIGERにおけるAクラスの道路が‘住宅用’か‘未分類’かなどだ。私はソフトウェアを書くことよりも、こうしたタグ変換の作業をコミュニティのほかのメンバーたちと一緒に進めるのにずっと多くの時間を費やした」
関係者全員が満足できる属性マッピングが出来上がった時点で、Hansen氏は国勢調査局のWebサイトからTIGERのデータセットを群単位でダウンロードし、自宅のコンピュータでその変換スクリプトを実行した。結果として得られたOSM互換データセットの構成オブジェクト（ノード、道路のセグメントなど）は、379,836,373件に及んだ。
このデータの変換には作業を休みなく続けて何日もかかったが、そのうえに稼働中のOSMサーバへのアップロードも行う必要があった。2005年に試みたインポート作業の事後分析を行ったHansen氏は、そのときの問題が変換されたデータを直接データベースにインポートしようとしたことにあると気付いた。「厳密なアップロード対象についてはほとんど管理されていなかった。だから整合性の点で問題が起こったのだと私は考えている。2度もアップロードされる部分があったり、アップロード時に手違いで欠落した地点があったりして、それらがあとになって1つのセグメントによって参照されていた」
信頼性を確保するために、当初からHansen氏は新しく変換したデータのアップロードにJOSMを利用していた。JOSMは、主としてGPS軌跡の注釈付与とアップロードに使用されるクライアント側アプリケーションである。これによってTIGERのデータがほかのすべてのOSM入力と同じAPIを通ることが保証され、2005年の試行時に起きたようなデータの破壊は回避された。
インポート完了は2008年5月
このインポート手法は正確でしかもOSMデータベースにデータを直にダンプするよりも安全だったが、耐えがたいほど処理に時間がかかった。完全なTIGERのデータセットのサイズがOSM収集データのTIGER形式でない部分の20倍以上もあることを考慮すると、JOSMの速度ではアップロード完了までに5年ないし10年かかるというのがHansen氏の見積もりだった。
結局、OSMチームはより優れた計画を作り上げることになった。Hansen氏は変換済みのデータファイルをOSMの地図サーバと同じラック上に設置されている開発マシンに転送し、管理者のTom Hughes氏が地図サーバの12のインポートデーモンのうち3つをその大量アップロード専用として割り当る形を取ったのだ。こうした改良を加えたデータインポートは9月初旬に開始された。
昼夜を問わず週末も休みなく実行を続ければ、TIGERデータのインポートは2008年の5月か6月には完了するはずである。現在のスループット、TIGERデータのインポート率、インポートが完了した群の一覧など、インポート実行の統計情報の推移は公開Webページで参照できる。興味のある人はこうしたインポートの進捗状況を参照して、OSMデータベース全体の総合統計情報と比較することができる。
改良されたTIGERインポート手法は以前のものよりもずっと高速だが、それでも完了までにはかなりの時間がかかる。Hansen氏は、この待ち時間の苦痛を緩和するある方法を編み出した。彼はまず、アップロード待ちのキュー内にある各郡のデータを人口の多い順に並べ替えることで、人口が最も多い地域から順に処理されるようにした。さらに、彼はデータ処理順序に関する要望も受け付けている。次にインポートしてもらいたい郡があれば、Hansen氏にその旨をメールで依頼すればキュー内の順位を上げてくれるかもしれない。
スケーラビリティに関する教訓
しかし、重要な要因は時間だけではない。TIGERデータのインポート開始後まもなく、データベース用マシン自体のハードディスク領域が何週間後には足りなくなることが明らかになった。
9月27日にストレージの容量を追加し終えたHughes氏は、途中で起こり得るもっと複雑な事態にも備えている、と話す。「確かに、これまでに我々が読み込んだTIGERデータはわずか1割にすぎないし、読み込んだデータや世界のほかの地域のデータが今後増えれば、もっと難しい問題が起こるかもしれない」
純粋にソフトウェアの側だけで起こるそうした問題の一例が、データベース用インデックスのサイズである。OSMチームはずっと前から既存のインデックスが非効率的なことを知っていた、とHughes氏は言う。OSMのデータベースではすべてのエントリが緯度と経度によってインデックス付けされているため、どんな地理的領域であっても何千という倍精度浮動小数点数の値の検索が必要になる。
しかし、TIGERデータのインポートが開始されてからというもの、インデックス数は大幅に増加し、以前は理論的なシステムの非効率性の問題だったものが具体的な問題として急速に表面化した。幸いにして、ある解決策がすでに功を奏していたため、先週OSMデータベースは地表をタイル状に分割することでサーバの負担をずっと軽減できる新しいインデックス方式に移行した。
鶏が先か卵が先か、はたまた虎が先か
TIGERのようなデータセットの大量インポートは、以前OSMで使われていた方法に比べれば大きな進化を遂げているが、HansenとHughesの両氏はOSMプロジェクトにとってはそれが最も重要なことだと信じている。Hansen氏は次のように語る。「実は、プロジェクト関係者は何年も前から米国での地図作成をあまり行わないように言われていた。いずれTIGERデータのアップロードによってその作業が無駄になるからだ」。そのため、地図作成業者はプロジェクトから遠ざけられた。だから何よりも、長い間ずっと地図作成を省みなくなっていた我々の役割は、実際にTIGERデータに取り組むことなのだと私は思っている」
ただし、TIGERデータが存在するからといって、ボランティアによる協力の必要性がなくなるわけではない、と彼は補足する。「私がTIGERデータに対して行っている処理というのは、自分の軌跡データを取り込み、そのデータと一致するように既存のTIGER道路データをドラッグさせることだ。これにより、ドライブ時にメモを取る時間や、自らのGPS軌跡データに含まれるすべての通りの名を探し出す膨大な時間が節約できる。私のワークフローは、基本的にTIGERデータと自分のGPSデータとで形状を一致させることになる。TIGERのデータは、我々がより良い地図を作成するための骨格の部分にあたる。ちょうど、現在のOSMデータの大半がGPS軌跡を骨格として作られたのと同じだ」
Hughes氏は、大規模なインポート処理とOSMボランティアの活動とは興味深い対照を成していると説明する。「我々の大半はおそらく、見た目に美しい地図を生み出す多くのデータを取り込むという考え方が気に入っているのだろう。また、それと同じくらい、外に出ていろいろな場所を探索してデータを集めるのが好きなのだ。つまり、大部分のデータの出所はある程度限られている。そのため、外に出て現地で調査を行うことで、成果物の品質を高めることができる。たとえ、どこかよそのデータを何らかのベースラインとして利用するところから始めるとしてもだ」
OSMにとって、大規模なインポートへの対処方法は単なるアカデミックな課題ではない。7月には、商用の地図を手がけるAutomotive Navigation Data（AND）社から大量の道路地図データセットがOSMプロジェクトに寄贈された。このデータセットには、オランダの全国土とインドおよび中国の主な幹線道路網が含まれていた。
大量の地図データをOSMに提供してくれそうな情報源はほかにもある。パブリックドメインのデータもあれば、Creative CommonsのShare Alike（同様に共有）ライセンスの下で地図データを公開するというOSMの方針と矛盾しないライセンスの下で利用できるデータもある。
また、TIGERデータ自体にも、現時点ではOSMのデータモデルにマッピングされていない情報（街路番号など）が含まれている。Hansen氏は、後々OSMモデルの拡張によって役立つときが来るのを見越して、こうした追加データもTIGERデータの変換時に保存している。Hughes氏によると、サードパーティ製のデータをOSMのデータモデルにうまく適合させることよりも、新たな情報提供元の候補を検討する際の議論のテーマとしてはライセンス供与の問題のほうが優先されるという。
たとえそのインポートが完了したとしても、TIGERデータが世界の全地表データに占める割合はほんの数パーセントに過ぎない。しかし、もっと重要なのは、そうしたインポートによってフリーの大規模マッピングソリューションとしてのOSMの実現可能性が実証されることであり、そのことがOSMプロジェクト自体と地図の利用者ひとりひとりに利益をもたらすことだろう。
