3Dとマップタイルの話
地図の視点と、リアルタイム地理空間情報認識の視点の差異をここ数年ずっと考え続けている。Luciadを扱っていると、その差異が差別化の源泉だからだ。
直感的には地図は、上空から撮った写真と一致するように思うが、実際には写真の中心しか一致しない。一般的な地図は、どの点をとっても真上から見たように作られている。標高は等高線としては表現されるが、2Dの位置には影響しない。
3Dマップのビューアーを考えると、平面ディスプレイであれば、3次元上のどこかの点から一般的には斜めに、適当な画角で切り取った画像を、その見ている人の位置を動かしたり、画角を変え（ズームし）たりして対象を認識している。標高差があると、2Dの矩形の表面積は、2Dの大きさより必ず大きくなる。例えば、人間自身は3立方mに収まるが、その大腸の表面積は100平方ｍに及ぶと言われている。地図の100平方ｍの上の地物の表面積は例えば、高層建築物を考えれば100平方mよりははるかに大きくなる。様々な技術進歩で、実際の存在を迅速に正確に補足することは可能になり、その精度は確実に向上していく。人間の測量、航空測量、準天頂衛星による計測や、ドローンを飛ばして計測する、LiDARを使うとか、日進月歩で進化していく。
リアルタイム地理空間状況認識を意識した場合、最終的なアウトプットを考えると、徐々に解像度が向上しているとはいえ、人間の認知限界からアウトプット画像は横1500、縦1000程度が目安になる。リアルにどこかを撮影した場合にデジカメの画像を取れば、得られる情報は約2Mピクセル程度。同じレベルの2Mピクセル程度の画像を3Dマップから得られれば、観測のために実際にその視点の場所に行く必要もドローンを飛ばす必要もなくなる。
Luciadのコンセプトで、良くできていると思うのは、結果としてアプリケーションが生成するのはその2Mピクセルの画像だという点に注目して、必要な事しかやらないというところにある。それを説明する前に、少し、3Dマップを理解するための技術的な背景を説明しておこう。
100mのビルの屋上から100m先の地面をフルサイズ35㎜のカメラに50㎜のレンズをつけて撮影したとすると、垂直画角は約27度。垂直方向の解像度を仮に1000ピクセルとすると1ピクセルの画角は0.027度という事になる。
注：上図は、カシオ計算機株式会社のkeisanサービスの「カメラの画角(視野角)を計算します」の実行結果をキャプチャしたもの。
100m先の地面までの距離は、約141mとなるので、中心部分の1ピクセルの大きさは縦7cm弱（下図b）という事になる。
http://keisan.casio.jp/exec/system/1177469593
一方、画角は約26度なので、手元側に13度、奥側に13度の幅がある。
手前の近い点までの距離は118mで、その位置を写しているピクセルの高さは5.56cmとなる。遠い点では、距離は189ｍ、ピクセル高は8.89cmとなる(厳密には、正面の角度で測った長さなので、通常はもっとずっと広大な領域を代表する値となる)。
http://keisan.casio.jp/exec/system/1177474036
ビル等の表面データ（これはこれで難物だが...）を含めて地図タイルの解像度が5cmより十分高ければ、その瞬間の動きは別にして地図タイルから写真と同等の画像を再現できるという事になる。
ちなみに、画面の一番上の点がビルから約160m、下の点が62mなので、カバーしなければいけない情報範囲は100m分。横幅は約150m分あれば良いので、解像度が仮に1㎝とすると10k×15k＝150Mピクセルという事になる。
最終画像のピクセル数が縦1k、横1.5kの1.5Mピクセルだから、倍率は100倍。タイルの解像度が5cmなら4倍という計算になる。本当は表面積で考えなければいけないので、はるかに複雑なのだが、とりあえず無視しておく。まずは、4倍から100倍程度の情報を必要とすると覚えておいてほしい。
さて、上例では、ビルから45度の角度で見降ろして写真を撮ったケースだが、次に空が上部3分の1になるように撮影するケースを考えてみよう。
カメラの画角を27度とおくと、正面を85.5度にすればちょうど空が3分の1を映り込む。この場合、正面に写っている場所までの距離がどうなるかと言うと、約1.3kmとなり、その位置での1ピクセルの高さは60cmとなる。一番手前は、273m先、ピクセル高10cmとなる。もちろん奥の距離は無限大になる（実際には、楕円体面なので最遠点は約38km※、ただし東京から見える富士山は約100km）。5km先の位置にあるもののピクセル当たりの高さは2.4m。
富士山を無視したら、3Dマップとは言えないが、とりあえず無視するとして、最遠点の40km先に注目して、左右の端の幅を60km、手前は273m先としてこれらの点を含む矩形は概ね2400平方kmとなる。前例が0.015平方kmなので、その差は16万倍である。最終的に生成する画像との倍率はこの4倍から100倍だと考えると、最終ファイルの大きさの64万倍から1600万倍のデータを処理することになる。
もちろん、データ容量的にも処理時間的にも現実的な訳がない。
ここで考えた方が良いのは、2400平方kmの奥地は最終画像ではピクセル高が15m程度になる点だ(改めて触れるが、厳密には、正面の角度で測った長さなので、通常はもっとずっと広大な領域を代表する値となる)。重要度から考えれば解像度は10m程度でも十分という事になる（解像度1000分の1、容量1M分の1となるが、実際のケースではさらにもっと解像度が低くても問題は無いだろう）。全体タイルは10mメッシュのものを取り込めば、24Mピクセルで良い。処理可能な大きさである（東京から富士山まで入れても大して負荷にならない）。ついで、正面辺りは、ピクセル高が60㎝程度だから、10cm程度の解像度で良い。一番手間はピクセル高が10㎝だから、1cmメッシュが欲しくなるかも知れないが、2400平方km分の1cmメッシュデータは全く必要ない。
逆に最終的に再現される画像から考え直すと、1.5Mのピクセル一つ一つに視点からの距離があり、ピクセルが表す対象の緯度経度と必要解像度が決まる。これを分析すれば、必要解像度とカバー範囲は事前に計算可能になる。この計算だけを事前にやってしまってから、必要なタイルデータを取り込めば、今のコンピュータであれば最終的に生成するための1.5Mピクセルの画像を生成するのに必要な元データを全部インメモリに展開することは十分に可能になる。それがhtml5のブラウザであってもである（WebGLは事実上必須だが）。
さて、最後にもう一度地図と状況認識の違いを考えてみよう。
もし、あなたが3D地図を3Dプリンタで作りたければ、求めている領域の求めているレベルの高精細なデータを全部処理しなければいけない。ただし、バッチで処理すれば良い。
一方、あなたが戦場や災害復旧に今取り組んでいるのであれば、今取り組んでいる場所に集中して、超高速で分析可能である必要がある。人間の認知能力を考えれば、画面で捉えられる情報は限られる。その情報だけを超高速、超高精細で扱えることに価値がある。
Luciadの製品群は、リアルタイム地理空間情報認識を強く意識して作られている。クライアント製品は、基本的に全部インメモリ指向で、アウトプット画像（Oculus用だったりするが）を生成する事に集中して作成されている。
サーバー製品であるFusionは、主に必要なタイルをクライアントに返す役割に重点を置いている。つまり、上の説明で長々とやってきたように、最終的に生成されるピクセルを計算するのに必要なタイルデータだけを迅速に返すのがその使命となっている。そのため、FusionにはLTS(Luciad Tile Services)という独自Webサービスが実装されている。もちろん、OGCのWMTSもサポートしている。
3Dプリンタで3D地図を形にする時にはLTSは必要ないが、リアルタイム処理がしたければ、この差は破壊的に大きい。
例えば、国土防衛、防災の観点でデータを整備するなら、どうしたって高解像度のデータを集めておかなければいけない。それは、地図であろうと状況認識であろうと同じである。しかし、リアルタイム情報分析の観点では、そのデータが、手元になければいけない理由は無く、必要なデータがリアルタイムに取れれば良いのである。もちろん、配布しておけばネットワークが切れても使えるメリットはあるが、配布されたデータの内で本当に利用されるデータは恐らく1%も無いだろう。また、データを配布すればするほど最新の状態に更新するコストは増加し、リアルタイム性は落ちる。
地図の視点で考えるアーキテクチャと状況認識で考えるアーキテクチャは大きく異なる事を意識しておいた方が良い。
ものすごく大きな違いなのだけれど、地理空間情報は見栄えが目を引いてしまうので、その違いを理解してもらう事がすごく難しいのだ。しかし、IoT時代を考えると、統合管理に取り組むのであれば是非Luciadの採用を検討すべきだと訴えたい。