JP2020173604A - 撮影計画立案装置およびその方法 - Google Patents

Abstract

【課題】潜在的に価値の高い画像を撮影するための撮影計画を作成する技術を提案することを目的とする。【解決手段】撮影計画立案装置は、複数のユーザについて、ユーザ名を含むユーザプロファイルを管理するユーザ管理テーブルを格納する記憶装置と、衛星撮影計画の立案を要求するために、ユーザ名とキーワードが入力される入力部と、キーワードからユーザの興味領域を特定して、ユーザ管理テーブルにユーザに対応してユーザ管理テーブルに格納する名寄せ部と、ユーザ管理テーブルに格納されているユーザ毎の興味領域における過去の撮影回数に基づき、地図上のグリッド毎に興味度を算出し、算出したユーザ毎の興味度をユーザ管理テーブルに格納されているユーザについて合算してヒートマップを作成し、ヒートマップに示される興味度の高いグリッドを撮影依頼領域とする撮影候補管理部とを有する。【選択図】図１Ｂ

Description

本発明は、付加価値の高い空撮画像を撮影するための撮影計画立案を行う技術に関する。

衛星画像は、一度の撮影で広域を撮影できる特性から、同一地域における土地の被覆状況が変化したことや、前回なかった地物が新しい画像では出現しているといったことを検出できる。衛星画像を用いた技術として、大規模災害の増加に伴い、迅速に広域の状況把握(物体抽出・変化抽出)ができる解析プラットフォームが求められている。広域の変化を長期間にわたってモニタし、意味のある情報を手に入れ続けるには多くの衛星画像が必要になる。従来、無料でダウンロードできる画像を提供する衛星にはＬａｎｄｓａｔやＭＯＤＩＳ（登録商標）があったが、マルチスペクトルのバンドにおいて解像度が３０ｍ、２５０ｍと低いものであった。

近年、高解像度センサを搭載した超小型衛星の登場により、衛星画像取得コストの低廉化が進んでいる。さらに、民間向けの高解像度衛星画像を提供する米Ｄｉｇｉｔａｌ Ｇｌｏｂｅ社がＧＢＤＸ ｐｌａｔｆｏｒｍを公開するなど、高解像度衛星画像の加入型アーカイブ利用サービスが黎明期を迎えており、多数の高解像度衛星画像を前提としたソリューションの検討が始まっている。

加入型アーカイブ利用サービスは、過去に撮影が行われた衛星画像を安価に所定回数利用できるサービスであるが、必ずしも利用者が見たい地域の画像が格納されているとは限らない。過去に誰かが撮影依頼した条件、例えばＡＯＩ (Ａｒｅａ ｏｆ Ｉｎｔｅｒｅｓｔ、興味領域)や撮影時刻などは、利用者が撮影依頼したいものと完全に適合することはほぼない、と考えられるからである。

アーカイブ利用者は、見たい時期のＡＯＩを撮影した衛星画像がない場合には、自身が撮影を依頼するか、あるいは偶発的に撮影が行われるのを待つ必要がある。多くの場合、見たい時期のＡＯＩの画像がない場合は、自身が撮影を依頼することになる。この際に、問題となるのは、衛星画像の新規撮影にかかるコストである。一部の例外を除いて、地上を撮影するための衛星機の数は限られている。限られた撮影機会を有効に活用するため、新規撮影には最低撮影面積に関する条件が設けられている。撮影機会を有効に使うことは撮影依頼が入った時でなくても重要なことであり、衛星軌道、被雲状況、撮影拘束時間、撮影角度などを適切に管理して最適なスケジュールで撮影が行われることが望ましい。

人工衛星に対して撮影条件を指定し、撮影の進捗状態を可視化する技術が特許文献１に開示されている。また、特許文献２では、過去の撮影と比較して一定量の変化を認めた地域について、新たな撮影計画を自動立案して衛星に対して通知する技術が開示されている。

特開２００９−９４３６号公報 特開２０１５−２８７５９号公報

撮影依頼が入っていないとき、いかに利用価値の高いデータを集めるかは衛星画像の撮影業者の抱える共通の問題である。衛星画像の撮影業者にとっては、後々に利用者が現れるような需給の高い領域を撮影して画像を格納（アーカイブ）しておくことが望ましい。災害が発生した時などは、誰からも撮影依頼が入らずとも被災地の撮影需要は高いことは明らかであるから、撮影時期は出来るだけ早くに、領域は被災地、と一意に決まる。衛星画像では、後々の解析で使われる可能性が高い座標と適切な時期を高い確度で推測することが求められる。

しかしながら、特許文献１は、衛星画像の進捗を表示するものであるが、撮影計画を作成することについては言及されていない。

一方、撮影計画に関する技術として、過去に撮影された画像の中から、一定量の変化を認めた地域について新たに撮影を行う技術が特許文献２に開示されているが、変化があった地域が将来価値の高い画像となるかは不明である。

そこで、本発明の目的は、潜在的に価値の高い画像を撮影するための撮影計画を作成する技術を提案することである。

上記課題を解決する本発明の撮影計画立案装置の一態様は、複数のユーザについて、ユーザ名を含むユーザプロファイルを管理するユーザ管理テーブルを格納する記憶装置と、衛星撮影計画の立案を要求するために、ユーザ名とキーワードが入力される入力部と、キーワードからユーザの興味領域を特定して、ユーザ管理テーブルにユーザに対応してユーザ管理テーブルに格納する名寄せ部と、ユーザ管理テーブルに格納されているユーザ毎の興味領域における過去の撮影回数に基づき、地図上のグリッド毎に興味度を算出し、算出したユーザ毎の興味度をユーザ管理テーブルに格納されているユーザについて合算してヒートマップを作成し、ヒートマップに示される興味度の高いグリッドを撮影依頼領域とする撮影候補管理部とを有する。

本発明によれば、潜在的に価値の高い撮影位置を決め、効率的な撮影計画を作成することができる。

実施例のハードウェア構成を説明する図である。 第１の実施例の機能ブロックを説明する図である。 第１の実施例の撮影計画立案装置のハードウェアブロック図である。 第１の実施例のユーザ管理テーブルを示した図である。 ユーザカテゴリＡの興味度を表す興味度マップを示した図である。 ユーザカテゴリＤの興味度を表す興味度マップを示した図である。 全ユーザの興味度を表すヒートマップを示した図である。 第１の実施例の業務テーブルを示した図である。 衛星画像の撮影タイムスロットを説明する図である。 第１の実施例のスケジューラの動作を説明する図である。 第２の実施例の機能ブロックを説明する図である。 第３の実施例のスケジューラの動作を説明する図である。 撮影角度毎に管理されたユーザの興味度マップの作成手順を説明する図である。 第４の実施例の機能ブロックを説明する図である。

本発明を実施する為の形態について、いくつかの実施の形態を挙げて説明する。以下の説明において、図中で同じ符号番号がついたものは、同様の動作を行うため、説明を省略する。一部動作が異なる派生形については、同じ符号番号の末尾にハイフン及びアルファベットをつけて表現する。

実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

以下の説明では、［ＡＡＡテーブル］の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないため、［ＡＡＡテーブル］は［ＡＡＡ情報］と説明することができる。

また、以下の説明では、［ＣＰＵ］は、１以上のプロセッサを含むＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔである。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。

また、以下の説明では、［プログラム］を動作の主体として処理を説明する場合があるが、プログラムは、ＣＰＵによって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）等を用いながら行うため、実際の処理の主体はＣＰＵである。従って、プログラムを動作の主体として説明された処理は、プロセッサが処理主体と説明されても良い。また、プロセッサが行う処理の一部又は全部をＡｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ（ＡＳＩＣ）やＦｉｅｌｄ-Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ（ＦＰＧＡ）等のハードウェア回路が行っても良い。

コンピュータプログラムは、プログラムソースから装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ、又は、計算機が読み取り可能な記憶メディアであってもよい。

付加価値の高い空撮画像を撮影するための撮影計画立案においては、将来価値の高くなる撮影位置を予測する必要がある。将来、価値の高くなる撮影位置を決めるためには、撮影計画を、過去に実績のあるユーザからの撮影依頼内容に近い条件に寄せることが効果的である。つまり、経験則に基づく撮影条件の決定方法を形式知化することが有効である。定期的に同じ撮影位置について撮影依頼を行うユーザは、将来においても同様の依頼をすることが多いからである。

また、衛星を使って空撮する運用会社が撮影計画を公開すると、ユーザは自身の興味のある領域(興味領域)について不必要な撮影依頼をしなくて済む。一方、運用会社もユーザから興味領域を公開してもらうと、潜在ユーザの興味範囲を空き時間を使って撮影できるようになり、結果として低コストでサービスを提供することができる。これにより、コストネックで撮影を遠慮していたユーザの需要を掘り起こすことができる。

実施例１の撮影計画立案（スケジューリング）について説明する。実施例１において重要な点の一つとして、衛星を使って空撮する運用会社が撮影依頼の入っていないタイミングで如何にユーザにとって価値の高い画像を撮影するか、という点がある。

図１Ａに、実施例１のハードウェア構成を示す。宇宙の軌道上を周回する衛星群５０と、衛星群５０と無線により通信を行う衛星通信装置１０、衛星５０に対して撮影命令を、衛星通信装置１０を介して送信する撮影計画立案装置３０で構成される。この衛星通信装置１０と撮影計画立案装置３０とで、撮影計画立案システムを構成する。撮影計画立案装置３０は、衛星の撮影姿勢やタイミング調整を行う撮影スケジュールを作成する役割を担い、作成された撮影スケジュールは衛星通信装置１０を介して衛星５０に送信される。撮影計画立案装置３０においてスケジュールの作成を行うための計算リソースは、ローカルに配置されたコンピュータであってもよいし、さらに外部拠点に設置されたコンピュータ、たとえばクラウドコンピュータ上のリソースであってもよい。

図１Ｂに撮影計画立案システムの機能ブロックを示す。実施例１において、スケジュールの作成を行うための契機は、衛星撮影計画の立案を要求するユーザから、入力部であるキーワード解析部３００に入力される、ユーザ名とキーワード入力である。ユーザ名は、ユーザを識別できるユーザ識別情報であれば、必ずしもユーザ名である必要はない。キーワード解析部３００は、入力されたキーワードとユーザ名を解析し、入力したキーワードに地名を示す固有名詞が入っているか判断し、入っていない場合には、地名を含めるように応答を返す。多くの場合、この時点では地名は、撮影場所を一意に特定できる住所やＡＯＩの形式で与えられていないことが想定される。例えば、ユーザが「神奈川県、港」と入力したと仮定すると、撮影候補は広く、あいまいさが残存している。

ユーザが入力した「神奈川県、港」といった、あいまいさが残る情報から、ＡＯＩの住所を特定するため、Ｗｅｂクローラ３０１は、検索エンジンを用いて、「神奈川県、港」に関するホームページの情報を収集し、収集した情報を住所探索部３０２に送る。住所探索部３０２は、入力されたキーワードや収集されたホームページのテキスト情報の中から、例えば「横浜港」「横須賀港」などの住所情報を抽出し、ユーザ名と共に名寄せ部３０３に出力する。Ｗｅｂクローラ３０１は、例えばＷｅｂスクレイピングのような技術を使い、ホームページからテキスト情報をロボット的に収集する。例えば、横浜港や横須賀港の公式ホームページの中からアクセス情報、沿革情報のページをクロールして、住所を抽出してリストアップする。例えば、横浜港を検索すると、横浜市港湾局のホームページがヒットし、ホームページ下部に横浜市港湾局の住所が出ているので、郵便番号などをキーとして住所情報を収集する。ホームページのＵＲＬ、住所情報、ホームページオーナーの名前、使用したＷｅｂクローラが使用したキーワード等を名寄せ部３０３に対して通知する。

名寄せ部３０３は、住所探索部３０２で抽出された住所情報、例えば、「横浜港」「横須賀港」から別の呼び方をする同じ港を纏める、所謂名寄せを行う。名寄せ部３０３は、キーワード解析部３００に入力されたユーザ名とキーワードを、名寄せ部３０３で名寄せされた住所とを対応付けて出力する。名寄せ部３０３から出力される住所が、キーワードから特定された興味領域となる。

記憶装置３２０には、図２で示すユーザ管理テーブルＴ１の内、興味領域Ｔ１５を除いた情報が予めユーザのプロファイルとしてユーザ毎に格納されている。名寄せ部３０３は、ユーザ名をキーとして対応する住所情報をユーザ管理テーブルＴ１の興味領域Ｔ１５に格納する。

名寄せ部３０３は、住所情報の名寄せだけでなく、ユーザプロファイルを解読し、同じ会社のユーザや類似ユーザを名寄せして、図２のユーザ管理テーブルＴ１のように管理する。類似ユーザについては、同じユーザとして取り扱ったほうが、衛星画像の撮影として効率的となるからである。そのため、類似ユーザは、名称が類似していることの他、解析業務、業種が類似するユーザも名寄せ部３０３によって名寄せする。

図２は、名寄せ部３０３によって、ユーザプロファイルを管理するためのユーザ管理テーブルＴ１を示したものである。記憶装置３２０は、ユーザ管理テーブルＴ１を格納し、名寄せ部３０３の制御の下、情報を逐次更新追加する。例えば、キーワード解釈部３００から新規ユーザが入力された場合、名寄せ部３０３によって、ユーザ管理テーブルＴ１のエントリーが追加される。

ユーザ管理テーブルＴ１のＩＤ Ｔ１１は、各ユーザを一意に識別するための識別情報として、例えば「０」を格納する。ユーザ名 法人名 Ｔ１２は、ユーザの名前として、例えば「〇〇社」を格納する。業種Ｔ１３は、識別情報によって識別されるユーザの業種として、例えば「ＧＩＳ（Ｇｅｏｇｐｒａｈｉｃａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ）」を格納する。また、ＧＩＳ ユーザカテゴリＴ１４は、識別情報によって識別されるユーザのＧＩＳカテゴリとして、例えば「Ａ」を格納する。このＧＩＳ ユーザカテゴリＴ１４については、後に詳述する。

興味領域Ｔ１５は、識別情報によって識別されるユーザの興味領域として、例えば「××市某所」を格納する。この興味領域Ｔ１５は、ユーザからキーワード解析部３００に入力されるキーワードを基に、住所探索部３０２で抽出された住所情報が入力されたユーザ名と一致するユーザ名Ｔ１２に対応して入力される。

解析業務Ｔ１６は、識別情報によって識別されるユーザの解析業務として、例えば「差分検出」が格納される。過去撮影回数Ｔ１７は、識別情報やユーザ名によって識別されるユーザの撮影回数の内、興味領域Ｔ１５を撮影した回数、例えば、「１０」が格納される。同一のユーザが異なるキーワードを入力したことにより、異なる興味領域Ｔ１５がユーザ管理テーブルＴ１に格納された場合、興味領域毎に過去の撮影回数Ｔ１７が管理されるようにエントリーを増やす。名寄せ部３０３によって名寄せした類似のユーザについても、同様に興味領域毎に過去の撮影回数Ｔ１７を管理する。

ユーザ管理テーブルＴ１において、前述した通り、ユーザ管理テーブルＴ１の内、興味領域Ｔ１５を除く、ユーザ識別情報ＩＤ Ｔ１１、ユーザ名 法人名 Ｔ１２、業種Ｔ１３、解析業務Ｔ１６、過去撮影回数Ｔ１７はユーザのプロファイルとして予め記憶装置３２０に登録され、逐次更新される。

ＧＩＳ ユーザカテゴリＴ１４において、業種Ｔ１３が「ＧＩＳ」として管理されている、地図情報を更新している「〇〇社」と同一カテゴリの業種を担っているユーザ名Ｔ１２が「△△社」で登録されているユーザは、類似ユーザとして取り扱うために、共に「Ａ」を格納する。例えば、ＧＩＳユーザカテゴリ「Ａ」は、ＧＩＳのプロフェッショナル企業群であり、省庁などの組織はＧＩＳユーザカテゴリ「Ｂ」として登録して、各ユーザを一定の区分毎に分けて管理する。この他、ＧＩＳを直接取り扱ってはいないものの、大規模な住所情報をもつ保険会社はＧＩＳユーザカテゴリ「Ｃ」として登録し、農業の管理組合はＧＩＳユーザカテゴリ「Ｄ」として登録し、インフラ等の公共機関などはＧＩＳユーザカテゴリ「Ｚ」とするなど、業種・業務の近いユーザを同一カテゴリに入れる。ＧＩＳユーザカテゴリ毎に過去撮影回数を集計し、過去に撮影された回数が多いカテゴリに属するユーザの処理は優先して取り扱うなどの処理をしてもよい。過去撮影回数Ｔ１７の多いカテゴリに属するユーザは、将来も多くの撮影依頼を行う可能性が高いからである。

ここで、過去撮影回数Ｔ１７は、実際に興味領域Ｔ１５を撮影した回数の他、撮影オーダーが入らずとも、興味範囲の大部分または全てを含む撮影が実行された場合にはシーンが撮影されたとして、撮影回数をカウントアップしても良い。但し、オーダーで撮影された領域ではないから、1以下の係数をかけて回数として管理しても良い。また、偶然撮影された回数として別途管理してカウントアップして良い。業種ごとに，ユーザがどういった業務を行っているかの傾向もオーダー済みユーザの情報から予想し、潜在ユーザの業務内容についても類推しても良い。

ユーザ名には所在地の地名情報が含まれていて、所在地がすなわち興味領域であることも多い。ここでいう興味領域Ｔ１５には、ユーザ登録時にユーザ自身に記入してもらったものだけでなく、ユーザ名に含まれる地名情報、ユーザ名をインターネットで検索した時に得られるホームページの住所情報などを含んでよい。ユーザ管理テーブルＴ１は過去の実績を反映していくため、撮影依頼が入るたびに、撮影依頼に含まれるユーザ名や興味領域を順次追加していくとよい。

図１Ｂに戻り、ＡＯＩ候補作成部３０６は、名寄せ部３０３から興味領域として入力されると、緯度・経度に変換するジオコーディングを行い、撮影すべき興味領域Ｔ１５（ＡＯＩ）の中心点を決定する。

もし、この時点で住所情報が不十分で、検索場所が絞られていなかった場合、画像解析部３１１にて、過去に撮影された衛星画像を用いてＡＯＩ候補を検出するとよい。例えば港を検出するには、ＡＯＩ候補作成部３０６が「港」という情報を画像解析部３１１に送り、画像解析部３１１は、アーカイブ画像から海岸沿いを探索し、桟橋と停泊船舶を検出する。工場や発電所などの大型の施設、商業施設を検索する場合は、画像解析部３１１はアーカイブ画像から時系列画像を比較して、広大な更地を検出し、徐々に建物が増えていくことを検出する。この検索には、枚数が十分に必要になるから、時系列画像を扱うには低解像度画像の使用が都合がよい。

画像解析部３１１にてＡＯＩ候補を含む衛星画像を抽出した場合、衛星画像は通常画像の右上の地点に関する座標情報を持っているから、ＡＯＩ候補作成部３０６は画像の座標情報を用いて衛星画像中の各ピクセルについて座標情報（緯度、経度）を求めることができる。求めた座標情報は、ＡＯＩ候補作成部３０６を介して撮影候補管理部３０７に送られる。

ＡＯＩ候補作成部３０６からの座標情報をすべてスケジューラ３０８に入力すると、数少ない衛星画像の撮影機会を浪費してしまうから、撮影候補管理部３０７が実際に撮影を行うかどうかを興味度として数値化して判断する。例えば、興味度が一定の閾値を超えた領域の座標情報のみを、撮影依頼領域としてスケジューラ３０８に出力する。これにより、将来需要が生じる可能性の高い衛星画像を、限られた撮影機会で撮影することができる。
興味度は、各ユーザに対し、地図上のエリアを分割したグリッド毎に計算され、記憶装置３２０に記憶される。

図３Ａは、業種Ｔ１３がＧＩＳユーザカテゴリＡの興味度の興味度マップを示したものである。図３Ａは、地図上のエリアを横方向（Ｘ方向）に３、縦方向（Ｙ方向）に３分割したグリッドで表したもので、それぞれのグリッドを（Ｘ，Ｙ）で表している。グリッドＡ１１のＡは、ユーザカテゴリを示し、１１は座標情報（Ｘ，Ｙ）に対応する。つまり、グリッドＡ１１は、ＧＩＳユーザカテゴリＡに対するグリッドで示された興味度が「１」であることを示している。

グリッドＡ２２は「３」となり、最も高い興味度を示す。グリッドＡ３３の興味度は「０」で、ＧＩＳユーザカテゴリＡのユーザはこの領域の衛星画像には興味がないこと、即ち、将来撮影依頼を受ける可能性が低いことを示している。ＧＩＳユーザカテゴリＡの業種はＧＩＳのため、広いエリアの衛星画像を撮影依頼する可能性が高いため、ほぼ全てのグリッドに興味度を示す数値が入っている。

同様に、図３Ｂは、ＧＩＳユーザカテゴリＤのユーザであり、業種Ｔ１３が農業組合のユーザの興味度の興味度マップを示したものである。ユーザカテゴリＤに属する農業組合のユーザは、農業組合が属するエリアに該当するグリッドのみに興味があるため、グリッドＤ３３のみに興味度「２」を示す数値が入っている。

図３Ａ、図３Ｂに示した各グリッドの興味度は、対応するグリッドにおける将来の画像化値を数値化したものである。興味度は、当該グリッドの過去の撮影回数、ユーザカテゴリに基づいて計算する。興味度の簡単な計算方法として、グリッド毎に過去の撮影回数にユーザカテゴリ毎の係数をかけて算出する。グリッド毎の撮影回数は、図２の興味領域Ｔ１５に対応して管理される過去撮影回数Ｔ１７から求めることができる。ユーザカテゴリ毎の係数は、ユーザカテゴリＡからＺの内、ユーザカテゴリＡが最も大きく、ユーザカテゴリＺを最も小さくするようにする。

ＧＩＳがプロフェッショナルであるほど、興味範囲が大きいか、三次元化の需要が強いことが想定されるから、ＡＯＩに相当するグリッド数で素点を分配し、さらに、三次元化の場合はその方向も加味して興味度を算出してもよい。また、収量予測に使う場合など、撮影期間に限定がある場合の興味度の点数は、時期がずれていればクリアしてもよい。

図３Ａや図３Ｂに示したユーザ毎の興味度マップを、ユーザ管理テーブルＴ１に格納されている全ての登録ユーザについて合算して全ユーザの興味度のヒートマップを示したものが図３Ｃである。

図３Ｃを拡大すると、グリッド上により、撮影方向毎（オフナディア角毎）の細かい興味度が示される。三次元撮影が重要となるＡＯＩでは、オフナディア角毎の興味度が重要となるからである。これは三次元化に使われるＭＶＳ（Ｍｕｌｔｉ Ｖｉｅｗ Ｓｔｅｒｅｏ）技術が多方向からの視点が必要とするためであり、三次元化の必要性の高い領域は、各撮影方向からの興味度で管理し、これらの合算でその領域の興味度を決定する。

撮影方向は、水平面を４５度で分割する８方向である。図３Ｃでは、８方向の内、３方向の興味度を示している。該当するグリットの８方向全ての興味度を合算した数値が、「１５」である。三次元化のためには、斜め方向からの情報も必要となるから、８方向のそれぞれに２種類のピッチ角（どれだけ傾けたか）を加えた１６方向および直上方向の立体角で管理するとよい。１６方向は目安であり細かく管理してもよい。一度撮影が行われても、その撮影によって、１６方向のうち特定の方向しか撮影された扱いにならないから、全ての方向から撮影が行われたと認識されるまでは当該地域の撮影フラグは完了にならないようにする。

撮影候補管理部３０７は、図３Ｃのような撮影候補地点のグリッド毎の興味度を随時アップデートしていく。ユーザが撮影したい時期には偏りがあるはずである。よって、図３Ｃのフートマップを時系列に管理する仕組みを提供しても良い。

図３Ｃに示すような興味度のヒートマップを、撮影候補表示部３１２に表示して将来ユーザとなる第３者に公開すると、衛星画像を撮影依頼したことのないユーザでも、将来の撮影可能性を予測することができ、重複したエリアについて新規の撮影依頼を行うことを防止することができる。また、ヒートマップにより興味度が低いエリアについて、衛星画像を入手したい場合には、新規に撮影依頼しなければならないことが把握できる。興味度のヒートマップは、撮影候補表示部３１２に表示することの他、ネットワークを介してユーザのスマートフォンやＰＣ等のユーザ端末に送信しても良い。

撮影条件管理部３０４は、名寄せ部３０３からユーザ管理テーブルＴ１の解析業務Ｔ１６を受領する。この情報から、図４に示す業務テーブルＴ２に格納された業務毎の典型的な撮影条件を抽出する。

記憶装置３２０は、業務テーブルＴ２を格納し、撮影条件管理部３０４の制御の下、業務テーブルＴ２の情報を逐次更新追加する。

図４の業務テーブルＴ２のＩＤ Ｔ２１は、各業務を一意に識別するための識別情報として、例えば「０」を格納する。解析業務 Ｔ２２は、識別情報によって識別される業務の解析業務として、例えば「差分検出」が格納される。解析業務Ｔ２２は図２の解析業務Ｔ１６と対応する。季節性考慮Ｔ２３は、識別情報によって識別される業務が、衛星画像を撮影する季節を考慮する必要があるかを示す情報として、例えば「要(夏)」が格納される。撮影方向Ｔ２４は、識別情報によって識別される業務の撮影方向として、例えば、「直上」が格納される。複数枚要否Ｔ２５は、識別情報によって識別される業務が、一つの撮影エリアに対して複数枚の撮影が必要かを示す情報として、例えば「要」が格納される。反射率変換Ｔ２６は、識別情報によって識別される業務が、反射率を考慮して画像を取得する必要がある場合に、その情報が格納される。

撮影管理部３０５は、記憶装置３２０に格納されている過去に撮影した衛星画像のアーカイブ画像を読み出し、アーカイブ画像の撮影時期・時刻や撮影角度、太陽角度など様々な撮影条件に関する情報を手に入れ、撮影条件管理部３０４からの撮影条件と比較する。アーカイブ画像からの読み出しは、撮影候補管理部３０７からの緯度と経度を含む画像についてのみ行っても良い。例えば、撮影管理部３０５は、業務管理テーブルＴ２の季節性考慮Ｔ２３が「要（夏）」となっている場合に、アーカイブ画像の撮影時期が夏であれば、アーカイブ画像によって新規撮影を不要と判断し、結果をスケジューラ３０８に出力する。もし、アーカイブ画像の撮影時期が冬であれば、新規撮影する必要があると判断し、その結果をスケジューラ３０８に出力する。

同様に、撮影管理部３０５は、アーカイブ画像の時刻や撮影角度や太陽角度が、業務テーブルＴ２の撮影方向Ｔ２４や反射率Ｔ２６を満足するか判断し、満足する場合には、アーカイブ画像を利用し、アーカイブ画像が利用できない場合に、スケジューラ３０８に撮影条件管理部３０４が読み出した撮影条件により、衛星画像を撮影依頼することで、撮影機会の効率的利用を可能とし、撮影コストを低減することができる。

撮影管理部３０５は、撮影条件管理部３０４から業務テーブルＴ２に格納された撮影条件と、撮影候補管理部３０７からヒートマップに示される興味度の高いグリッドが示されるグリッド情報とが入力され、このグリッド情報に対応するアーカイブ画像を記憶装置３２０から読み出す。つまり、グリッド情報により特定される領域を撮影したアーカイブ画像を読み出す。

撮影候補管理部３０７からのヒートマップ情報から一定の閾値以上のグリッドの座標情報から、処理対象のアーカイブ画像を絞り込む。撮影管理部３０５は絞り込んだアーカイブ画像が撮影条件管理部３０４からの撮影条件を満たしている場合には、アーカイブ画像を利用する。利用できない場合には、撮影候補管理部３０７からの座標情報と撮影条件管理部３０４からの撮影条件を、新規な撮影依頼としてスケジューラ３０８に出力する。

図９は、ユーザのプロファイル解析から、図３Ａ、図３Ｂ、図３Ｃに示したような興味度のヒートマップを更新する方法を示したものである。名寄せ部３０３は記憶装置３２０に格納されたユーザ管理テーブルＴ１から、ユーザのプロファイルを読み出す（Ｓ９０２）。名寄せ部３０３は読み出したユーザのプロファイルから解析業務Ｔ１６を推定する（Ｓ９０３）。撮影条件管理部３０４は、解析業務を把握すると業務テーブルＴ２より、撮影角度等の撮影条件を特定する（Ｓ９０４）。次に、スケジューラ３０８は、撮影条件に含まれる撮影法方向Ｔ２４等に基づいて、各グリッドの興味度を複数の撮影角度に分配する（Ｓ９０５）。これによって、図３Ｃに示したような撮影方向に応じた興味度を管理することができる。グリッド毎の興味度や撮影角度に分配された興味度は、撮影候補表示部３１２に入力され、表示される。

スケジューラ３０８は、撮影管理部３０５から受け取った、過去の撮影統計と、撮影候補管理部３０７から受け取った撮影候補のヒートマップの情報と、天気予報の情報を用いて、衛星画像の撮影のスケジュールの作成を行う。スケジューラ３０８の動作の内、衛星画像の撮影のスケジュール作成そのものは、実際に撮影依頼があった場合に、その撮影依頼に含まれる撮影場所（差表情報）、撮影時期、撮影角度等の撮影条件に基づいて、衛星画像の撮影スケジュールを行う場合と同様に行うことができる。実施例１においては、実際の撮影依頼に含まれる撮影条件の代わりに、将来の撮影依頼の可能性の高い撮影条件をスケジューラに入力することで、将来需要が高い画像を予め撮影する。これにより、効率的に衛星画像を撮影することができる。

スケジューラ３０８に入力される衛星の撮影角度は細かく制御しすぎても、設定しなおしのリードタイムや部品の摩耗があるから、多くとも１日に２〜３回程度にするとよい。一般にオフナディア角と呼ばれる衛星の撮影方向と地上の鉛直方向がなす角は、衛星の進行方向(アジマス)について、仰角をどれだけ傾けたか(ピッチ角)、左右にどれだけ傾けたか(ヨー角)によって計算されるから、これらアジマス、ピッチ角、ヨー角の３点の姿勢情報と、変更にかかるタイミングの情報をスケジュールの作成の情報として送信すればよい。

図６に本発明のスケジューラ３０８の動作概略を示す。

スケジューラの動作概要を説明するために、衛星の撮影について、アジマス角、ヨー角、ピッチ角と、撮影日によって、衛星軌道から決まる撮影可能エリアであるスリット、スリットに含まれるスロットの関係を図５に示している。興味度が高いグリッドを撮影するスロットをグレーで示している。このグレーで示す場所で衛星画像を撮影するためのスケジュールをスケジューラ３０８は作成する。

まず、スケジューラ３０８は、図５に示した日毎に衛星の姿勢とライムスロットを決定するため、日毎に動作フローが開始される(ステップＳ６０１)。

次に、各ヨー角、ピッチ角毎に以下の処理を行うループ処理を開始する(ステップＳ６０２)。

撮影候補は当然、興味度の点数が一番高いポイントから定めるべきであるから、スケジュール対象の軌道において、ヨー角・ピッチ角毎にストリップの予測をたてる（Ｓ６０３）。そして、当該ストリップにて回収できる興味度を算出する（ステップＳ６０４）。回収できる興味度とは、例えば、ストリップでカバーされるグリッドの興味度の合計を意味する。他のヨー角、ピッチ角のループで算出されたストリップの興味度と比較して評価する（ステップＳ６０４）。全てのヨー角、ピッチ角、必要な日数分の処理が終了すると、興味度の点数が高い領域を一番たくさん巻き込むヨー角とピッチ角を決定する(ステップＳ６０７)。

姿勢の変更すなわちスロット数は精々、数回程度とすれば、有限の試行回数で興味度の点数を評価できる。三次元化の管理がなされているグリッドの点数を回収するために、撮影されていない方向からの撮影をしないと興味度が合算されないように制約を加える。撮影の時期が指定されているグリッドの点数を回収するには、当該条件を満たしている必要があり、撮影時期にかからなければ、点数は回収されないものとしてカウントする。

また、光学衛星画像の最大の問題である被雲時には地上が撮影できないから、天気予報の情報は重要である。当該撮影予定時刻における被雲に関する予想を期待値として加え、点数を再評価しても良い。その場合、被雲が一定比率以上かかった衛星画像は使い物にならないから、当該領域の回収できる点数はほぼ０になるように調整する。一度撮影が行われたグリッドの興味度はクリアする。

このようにして決定した姿勢の情報とスロットの情報はスケジュールの作成の結果として、衛星通信送受信部１０ｂに送られ、無線信号に変換された後、アンテナ１０ａから電波を送信し、軌道上にやってくる衛星にインプットされる。軌道を回る衛星がアンテナの射程内に入るタイミングは限られており、衛星への撮影指令を出せるのは１拠点につき１日１回程度である。

また、実際にどのようなスケジュールで撮影が行われる予定であるかは、撮影候補表示部３１２に、図５で示すように、撮影ストリップの予想軌道と、撮影時間と、撮影姿勢の情報を付与し、スケジュールの情報として表示して公開してもよい。このようなスケジュールの情報に加えて、他のユーザがどの程度興味を持っているかを示す参考情報として図３に示したような興味度マップを公開してもよい。これら公開は、撮影候補表示部３１２に表示されることの他、ユーザのＰＣやスマートフォンに、スケジュールの情報や、ヒートマップ情報を送信することによって行われる。

天気予報の予測精度と更新頻度の必要性を鑑みるに、３日程度のスケジュールの作成をしておけば十分である。地上のアンテナと、衛星プラットフォームの間で通信が確保できるのであれば毎日細かく制御してもよい。

図１Ｃは、撮影計画立案装置のハードウェアの構成例である。図１Ｃにおいて、通信装置３５３、キーワード解析部３００を構成するキーボードやマウス等の入力装置（図示せず）、撮影候補表示部３１２を構成するディスプレイ等の出力装置（図示せず）、制御部であるＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３５１、メモリ３５２、記憶装置３２０を含んで構成されている。

ＣＰＵ３５１はメモリ３５２に格納されたプログラムにしたがって、各種機能を実現する。メモリに格納されたプログラムは、キーワード解釈、ＷＥＢクローラ、住所検索、名寄せ、撮影条件管理、撮影管理、ＡＯＩ候補作成、撮影候補管理、スケジューラの各プログラムであり、各プログラムを処理部３５１が実行することで、図１Ｂに示したキーワード解析部３００、ＷＥＢクローラ３０１、住所検索部３０２、名寄せ部３０３、撮影条件管理部３０４、撮影管理部３０５、ＡＯＩ候補作成部３０６、撮影候補管理部３０７、スケジューラ３０８等の各機能ブロックを実現する。

また、記憶装置３２０は、磁気ディスクドライブ、光磁気ドライブ、光ドライブ、レイド（ＲＡＩＤ）、ソリッドステートメモリデバイス、ソリッドステートドライブ等で構成され、ユーザ管理テーブルＴ１、業務テーブルＴ２、過去の衛星画像であるアーカイブ画像３１０、ユーザ毎の興味度を示した興味度マップ３３０が格納される。

以上、実施例１によれば、潜在的に価値の高い画像を撮影するための撮影計画を作成することができる。

また、衛星を使って空撮する運用会社が撮影計画を公開すると、ユーザは自身の興味領域について不必要な撮影依頼をしなくて済む。一方、運用会社もユーザから興味領域を公開してもらうと、潜在ユーザの興味範囲を空き時間を使って撮影できるようになり、結果として低コストでサービスを提供することができる。
さらに、コストネックで撮影を遠慮していたユーザの需要を掘り起こすことができる。

実施例２では、実施例１のようにキーワードからＡＯＩを類推せず、ユーザから直接的にＡＯＩを入力する場合の動作について説明する。

図７は、第２の実施例の機能ブロックを説明する図である。ＡＯＩ受付部７００は、実施例１の入力部に新たな機能として追加される。図７のＡＯＩ受付部７００は、ユーザがＡＯＩに関する情報をアップロードするインタフェースを提供する。ＡＯＩの指定方法は、住所録の形であってもよいし、ＥＳＲＩ Ｓｈａｐｅｆｉｌｅをはじめとするベクタデータの形式でもよいし、マスク画像のようにラスタデータの形式でもよい。実施例２では、図２に示したユーザ管理テーブルＴ１の興味領域Ｔ１５に、ＡＯＩ受付部７００からの出力である緯度、経度の座標情報が入力される。

Ｗｅｂクローラ３０１-Ａは、登録されたユーザのプロファイル情報から推測されるユーザの興味領域を登録するため、名前をキーとした関連ホームページをクロールして取得する。

住所探索部３０２は実施例１と同様に、収集したホームページから住所情報を抜き出し、ユーザ管理テーブルの、当該ユーザの興味領域に追記してよい。ただし、実施例２においては、ユーザから直接指定されたＡＯＩがあるから、それをメインの興味領域として扱うこととする。

ＡＯＩ候補作成部３０６-Ａは、住所録のような形式でＡＯＩを受け取ったならば、ジオコーディングにより、それらを緯度経度の情報に変換する。変換された緯度経度の情報は撮影候補管理部３０７に送られる。

撮影候補管理部３０７は、興味度のヒートマップを作成するが、ＡＯＩの入力を行ったユーザと、ＡＯＩの入力を行わなかったユーザ、例えばキーワード入力をしたユーザなどについて、興味度の評価方法を変更してもよい。例えば、ユーザによってＡＯＩが直接指定された場合には、指定しなかったユーザの推定ＡＯＩ領域に対して、設定する興味度をＮ倍として取り扱ってよい。ただしＮは１以上の数字である。つまり、ＡＯＩ受付部から入力された興味領域の興味度を、実施例１のキーワードに基づく興味領域より高くなるように計算する。これは、キーワードレベルで撮影場所を模索しているユーザと、見たい領域が確定していて衛星画像撮影の意欲が高いユーザの間で確度の高い情報を欲しがっている確率は後者の方が高いことを考慮に入れるための処置である。その他の部位の処理については、実施例１に示したものと同様の動作を行う。

以上、実施例２によれば、実施例１に加え、ユーザから直接的にＡＯＩを入力するので、より精度の高いＡＯＩを基礎とすることができる。

実施例３では、複数の衛星をスケジュールの作成する方法を説明する。
複数の衛星に対するスケジューラ動作は、基本的な動作は一つの衛星を動かす場合と同じである。しかし複数の衛星を使うから、撮影に関する柔軟性は上がっており、より細かい撮影角度の指定が出来る。例えば、業務の典型的な撮影条件を図４の業務テーブルＴ２に示したが、直上の撮影が望ましい業務向けの撮影を行う際には、無理に角度を付けた撮影が行われないよう、直上方向から以外の撮影で興味度がクリアされないように設定してもよい。

通常、斜めからの撮影は、ビルの倒れ込みの影響が大きくなったり、ＤＥＭ（各種測量により計測された平面位置及び標高値を用いた三次元座標を、デジタルで表現したものを）による衛星画像の補正が難しくなったり、後々の衛星画像の処理が困難になる。特に複数枚での利用が前提となる業務については、撮影方向の条件に関して、撮影条件を厳しくしてもよい。例えば、ユーザの興味度は、ユーザカテゴリ毎に優先順を決定できるように大小を定めればよいと説明したが、図３に示したように撮影方向毎に、興味度を分配するような仕組みを使って、衛星の撮影姿勢を含めた興味度の管理方式を提供する。これにより、スケジュールの作成の際に撮影角度まで含めた、衛星リソースの管理が可能となる。

図８に示すように、複数の衛星の撮影の空き状況を確認し、スケジュール対象の日程に関して、撮影依頼が入っていない衛星を対象にスケジュールの作成を実施する。単一衛星に対してのスケジュール時と同様に、軌道とストリップを推測し、天気予報から被雲条件をそれぞれの衛星について予測する。図８の処理は、最初のステップに衛星の数だけ処理ループが追加されたことを除いて基本的に図６同様である。

以上、実施例３によれば、実施例１及び２に加え、さらに、複数の衛星を用いて、効率よく撮影計画を作成することができる。

実施例４は、ユーザからの入力を前提とせず、ニュースを検出した時に撮影が行われるような仕組みを提供する。例えば、ニュースは、過去の撮影された興味領域に関するものについて、検出する。

図１０に示すように、Ｗｅｂクローラ３０１-Ｂは、常時インターネット上に公開されるニュース記事を収集する。ニュース解釈部８００は、実施例１の入力部に新たな機能として追加される。ニュース解釈部８００は収集された記事にタグ付けを行うとともに、ニュースから読み取れる住所に関する情報を収集する。収集された住所の情報は、実施例１〜３のように特定のユーザが存在する場合と同様に、タグ付けした内容をユーザに見立て、ユーザカテゴリを割り当てて、興味領域に、収集された住所の情報を格納する。
つまり、図２のユーザ名Ｔ１２の代わりにニュースに付されたタグが登録される。

記事の中から、住所情報が得られなかった記事はここでは取り扱わない。Ｗｅｂクローラ３０１-Ｂは、ニュースサイトだけでなく、ＳＮＳサイトのように検索エンジンからは見えないインターネット上のリソースに対しても、データ収集の範囲に含めてもよい。

一般にニュース記事に完全な住所情報が載っていることは稀であるから、実施例１で示したように、画像解析部３１１によって、着目すべき領域に絞り込むために画像処理とセットで撮影範囲を絞り込む必要がある。ここで、意図している画像処理とは、スケジュールの作成の対象となる衛星で得られる画像ではなく、無償で提供されている低解像度画像を使い、差分検知などの画像処理を行った結果、差分が見られたところを抽出する処理のことを意図している。

画像収集部８０１は、無償の衛星画像を公開しているサイトに対して、ダウンロード申請をかけてアーカイブ画像を収集する仕組みを提供する。例えば、無償で公開されている光学衛星には、ＭＯＤＩＳ、Ｌａｎｄｓａｔ、Ｓｅｎｔｉｎｅｌなどがあるが、これらのサイトに対して当該ニュースの地名が入った画像のダウンロード要求を出し、複数枚の画像をダウンロードした後、輝度補正、被雲除去、オルソ補正などの適切な前処理を施し、変化抽出を行う。近年、ＡｍａｚｏｎやＧｏｏｇｌｅといった米国のプラットフォーム企業が、画像のデータセットとして、これらの無償衛星画像をある程度まとめてカタログアーカイブとして配布するサービスを行っている。オリジナルサイトに対してロボットダウンロードを毎日行うとアクセス負荷をかけてしまうから、こういったカタログアーカイブサービスを用いて、必ずしも最新ではないが、アクセス負荷が比較的小さいサービスを使って、画像を収集し、変化抽出処理を常に準備しておくとよい。

ニュース解釈部８００は、過去に撮影を行ったユーザが撮影を依頼した地域について、当該ユーザの行った業務を類推し、撮影時期において当該撮影地域に関して報道されたニュース記事を検索し、タグ付けして管理する。これにより、将来撮影を誘発するニュース記事として、タグ情報の頭出しが可能なようにしておく。

検索されたニュースと撮影された衛星画像の時期、領域の情報を組み合わせとして保持し、将来に、同様のタグの記事へのアクセス数が一気に増えてきた場合に、記事の中から撮影対象地域を抽出して、画像解析部３１１による変化抽出等と組み合わせて、実際に高解像度な衛星を撮影するかどうかを判断して決める。

この場合の興味度の単純な計算方法として、グリッド毎にヒットしたニュースの件数に係数をかけて求めることができる。

ＳＮＳであればトレンドに入るほど一挙にアクセスが集まった状態が続くことで、係数を高く設定するとよい。一般に、ユーザから撮影範囲の希望を受け付けた場合に比べて、コンピュータが自発的にニュースサイトやＳＮＳから撮影範囲を決める方法は、真に撮影が必要になる確率は低いから、ユーザから直接的に撮影地域を指定する実施例１〜３に比べて、撮影の興味度としては小さい値となるように係数を1以下に設定するとよい。

以上、実施例４によれば、実施例１から３に加え、さらに、ユーザからの情報がなくても、ニュースなどの情報に基づいて、将来需要が見込めるエリアの衛星画像を撮影することができる。

実施例１から実施例４において説明した形態は単体で動作する必要はなく、組み合わせて使用してもよい。

以上のように、本実施の形態によれば、潜在的に価値の高い画像を撮影するための撮影計画を作成することができる。

また、衛星を使って空撮する運用会社が撮影計画を公開すると、ユーザは自身の興味領域について不必要な撮影依頼を防止することができる。一方、運用会社もユーザから興味領域を公開してもらうと、潜在ユーザの興味範囲を空き時間を使って撮影できるようになり、結果として低コストでサービスを提供することができる。

さらに、コストネックで撮影を遠慮していたユーザの需要を掘り起こすことができる。

また、ユーザから直接的にＡＯＩを入力するので、より精度の高いＡＯＩを基礎とすることができる。

また、複数の衛星を用いて、効率よく撮影計画を作成することができる。

さらに、ユーザからの情報がなくても、ニュースなどの情報に基づいて、将来需要が見込めるエリアの衛星画像を撮影することができる。

１０：衛星通信装置、
３０：撮影計画立案装置、
５０：衛星、
３００：キーワード解析部、
３０１：Ｗｅｂクローラ、
３０２：住所探索部、
３０３：名寄せ部、
３０４：撮影条件管理部、
３０５：撮影管理部、
３０６：ＡＯＩ候補作成部、
３０７：撮影候補管理部、
３０８：スケジューラ、
３１１：画像解析部、
３１２：撮影候補表示部、
３２０：記憶装置。

Claims (10)

1. 複数のユーザについて、ユーザ名を含むユーザプロファイルを管理するユーザ管理テーブルを格納する記憶装置と、
   衛星撮影計画の立案を要求するために、ユーザ名とキーワードが入力される入力部と、
   前記キーワードから前記ユーザの興味領域を特定して、前記ユーザ管理テーブルに前記ユーザに対応して前記ユーザ管理テーブルに格納する名寄せ部と、
   前記ユーザ管理テーブルに格納されているユーザ毎の興味領域における過去の撮影回数に基づき、地図上のグリッド毎に興味度を算出し、前記算出したユーザ毎の興味度を前記ユーザ管理テーブルに格納されているユーザについて合算してヒートマップを作成し、前記ヒートマップに示される興味度の高いグリッドを撮影依頼領域とする撮影候補管理部とを有することを特徴とする撮影計画立案装置。
2. 請求項１に記載の撮影計画立案装置において、
   前記ヒートマップに示される興味度をより回収できるよう衛星撮影のスケジュールを立案するスケジューラを有することを特徴とする撮影計画立案装置。
3. 請求項１に記載の撮影計画立案装置において、
   前記記憶装置に格納される前記ユーザ管理テーブルは、各ユーザに対応して解析業務が記憶されており、
   前記記憶装置は、さらに、解析業務毎に撮影条件が格納される業務テーブルと、過去の衛星画像をアーカイブ画像として格納し、
   前記名寄せ部が前記入力部から入力されたユーザ名に基づいて、前記ユーザ管理テーブルから読み出した解析業務が入力されると、前記業務テーブルに基づいて、撮影条件を読み出す撮影条件管理部と、
   前記撮影条件管理部が読み出した撮影条件と、前記アーカイブ画像の撮影条件を比較し、撮影条件が異なる場合に、前記撮影条件管理部が読み出した撮影条件により撮影依頼を行う撮影管理部を有することを特徴とする撮影計画立案装置。
4. 請求項３に記載の撮影計画立案装置において、
   前記撮影管理部による前記撮影条件管理部が読み出した撮影条件と比較される前記アーカイブ画像は、
   前記撮影候補管理部から前記ヒートマップに示される興味度の高いグリッド情報が入力され、前記グリッド情報を含むアーカイブ画像であることを特徴とする撮影計画立案装置。
5. 請求項３に記載の撮影計画立案装置において、
   前記入力部から入力されるキーワードから住所情報を抽出する住所探索部を有し、
   前記名寄せ部は、前記住所探索部から入力される住所情報の名寄せ処理を行うことを特徴とする撮影計画立案装置。
6. 請求項３に記載の撮影計画立案装置において、
   前記入力部は、ユーザから興味領域を直接入力されるＡＯＩ受付部であり、
   前記撮影候補管理部は、前記ＡＯＩ受付部から入力された興味領域の興味度を、前記キーワードに基づく興味領域より高く計算することを特徴とする撮影計画立案装置。
7. 請求項３に記載の撮影計画立案装置において、
   前記入力部は、ニュース記事から住所を抽出する収集するニュース解釈部を有することを特徴とする撮影計画立案装置。
8. 請求項２に記載の撮影計画立案装置において、
   前記撮影候補管理部により作成されたヒートマップを表示する撮影候補表示部を有することを特徴とする撮影計画立案装置。
9. 請求項８に記載の撮影計画立案装置において、
   前記撮影候補表示部は、スケジューラによって立案された衛星撮影のスケジュールを表示することを特徴とする撮影計画立案装置。
10. 記憶装置と制御部とを有する撮影計画立案装置における撮影計画立案方法であって、
    前記記憶装置は、複数のユーザについて、ユーザ名を含むユーザプロファイルを管理するユーザ管理テーブルを格納し、
    前記制御部は、
    衛星撮影計画の立案を要求するために、ユーザ名とキーワードが入力され、
    前記キーワードから前記ユーザの興味領域を特定して、前記ユーザ管理テーブルに前記ユーザに対応して前記ユーザ管理テーブルに格納し、
    前記ユーザ管理テーブルに格納されているユーザ毎の興味領域における過去の撮影回数に基づき、地図上のグリッド毎に興味度を算出し、前記算出したユーザ毎の興味度を前記ユーザ管理テーブルに格納されているユーザについて合算してヒートマップを作成し、前記ヒートマップに示される興味度の高いグリッドを撮影依頼領域とすることを特徴とする撮影計画立案方法。

Images