有用なツールを開発ご提供くださる作者のBackyさんに感謝申し上げます。



JDEM_AUTOとは

 JDEM_AUTOはBackyさんが作られた、FS用の標高メッシュシーナリーを作成するツールで、国土地理院のWEBから入手できる日本の標高データを処理して、FS用のbglファイルを作ってくれます。名前の「AUTO」の通り、データの入手以外はほとんど自動的に作業が進み、大変使いやすく有用なツールです。

<注意>

 国土地理院の標高データを処理して得られたbglは、国土地理院の承認を得ないまま公開・販売等することはできません。従って、基本的にはbglを自分で作成し自分で使うことになり、その意味でもJDEM_AUTOはFS環境の飛躍的UPに必須のツールです。



JDEM_AUTOの入手と起動

 現在(2012年3月)公開されているバージョンは1,2.3.0です。
 アプリはBackyさんのWEBからダウンロードします。ダウンロード後に任意のフォルダに解凍したら、あとはその中のJDEM10_Auto.exeを実行するだけです。



JDEM_AUTOの使い方

< 作者Backyさんからの重要アナウンス
 「JDEM_Autoのバグではないのですが、Resample.exeがフォルダー名やファイル名に空白が含まれていると正しく機能しないようです。」 


 SDKの中にあるresample.exeの仕様上、空白はだめのようですので、JDEM_AUTOで作業するとき、とにかくファイル名やフォルダ名に空白を入れないようにしましょう。

 それでは、以下に使用法を列記します。

**-- メッシュデータの入手 --**
 まず、標高メッシュデータを国土地理院のWEBの「基盤地図情報」のコーナーからダウンロードします。
 2012年3月にリニューアルされてからは登録制になったので、最初の1回目は登録作業が必要です。それから後はログインのみでOK。
 GML形式のデータをダウンロードします。


**-- 10mメッシュシーナリーの作成 --**

手順1.ファイルをドラッグ

 入手した10mメッシュデータを、zipファイルのままJDEM_AUTOの窓にドラグします。
 zipファイルの中には1個から数十個程度のxmlファイル(中身は標高データ)が格納されていますが、解凍する必要はありません。JDEM_AUTOが自動的に解凍して作業が行われます。
 zipファイルを自分で解凍し、得られたxmlファイルをドラッグしても構いませんが、zipファイルのままが相当に楽です。zipファイルの中のxmlファイルの内の幾つかを選んで処理したいとき以外は、zipファイルのままで問題ありません。

 ドラッグするzipファイルは1個でなくても、数個から10個以上ドラッグしても構いませんが、あまり多いと、下記の結合処理の設定如何によってはコンピューターの処理能力を超えるかもしれません。
 私は10個程度で、それぞれzipファイル毎に結合(=各アイテム毎に結合)する設定で使っています。

 作者Backyさんからの追加レクチャ(引用)
「ドラッグできるファイル形式ですが、zipとxmlなのですが、もうひとつ、xmlファイルが含まれているフォルダーをドラッグできます。フォルダーをドラッグして、アイテムごとに結合するとフォルダーの中のxmlファイルを結合して一個のbglを作ります。ですから、まとめたいxmlファイルをフォルダーに入れて名前をつけると、その名前で一個のbglができます。」


手順2.結合処理を指定

 zipファイル(またはxmlファイル)を窓にドラッグしたら、「結合処理」の項目のどちらかを選びます。

 (すべて結合)を選ぶと、窓にドラッグしたファイルすべてを結合して1個のbglファイルを作ります。
 xmlファイルの場合はこの(すべて結合)を選ばないと、それこそ膨大な数の小さなbglファイルが出来てしまいます。xmlファイルを処理する場合は、このオプションを選び任意のファイル名を指定します。
 zipファイルのまま処理する場合にこのオプションで処理すると、全てのzipファイルの中身が結合されて1個の巨大なbglファイルが出来ますが、コンピューターの処理能力を超える可能性があります。また必然的に、ダウンロードしたzipファイル名と違うbgl名になるので、後々の整理の際に不都合になります。
 従って、普通の場合には(各アイテム毎に結合)を選びます。

 (各アイテム毎に結合)を選ぶと、zipファイル毎に1個のbglファイルが作られます。
 bglファイル名は、自動的にzipファイル名と同じものが付けられます。


手順3.データ処理の方法を指定

 基本的にはJDEM10_Auto.doc(またはJDEM10_Auto.pdf)に書かれている通りに設定します。
Step1で-9999(=標高データ無しの数値)を0に置換。
  「置換」を選び、左側窓に-9999を入力。右側窓に0を入力。
Step2で値を100倍する。
  「数を掛ける」を選び、左側の窓は空白にしておき、右側窓に100を入力。
Step3は「何もしない」を指定。入力窓は空白にして構わない。
・一番下にある「FractionBits」を設定。
  通常の場合は0のままにしておく。高さ方向に1mの分解能で処理される。
  FractionBits=1にすると、高さ方向に0.5mの分解能で処理される。
    しかしファイルサイズは大きくなる。
  FractionBits=2にすると、高さ方向に0.25mの分解能で処理される。
    しかしファイルサイズはさらに大きくなる。また、標高は−8192m〜8192mまでしか扱えなくなるので、ヒマラヤ
    山脈のデータでも扱おうとすると、少し工夫が必要。(別記参照)
  FractionBits=3にすると、高さ方向に0.125mの分解能で処理される。
    しかしファイルサイズはさらに大きくなり、0の場合の約2倍近くになる。また標高は−4096m〜4096m(13ビット)
    までしか扱えなくなるので、日本の場合は問題ないが、4096mを超える標高がある地域のデータを扱うときには、
    上記の処理ステップで少し処理を追加する。(別記参照)
  FractionBits=4にすると、高さ方向に0.0625mの分解能で処理される。
    しかしファイルサイズは一層大きくなる。
    また、標高は−2048m〜2048m(12ビット)までしか扱えなくなるので、それを超える標高がある地域のデータを
    扱うときには、上記の処理ステップで少し処理を追加する。(別記参照)

 作者Backyさんからの追加レクチャ(引用)
「FSXでは標高データを1ポイントに対して16ビットの精度で格納しています。この16ビットの何ビットを小数点以下に割り当てるかを設定するのがFractionBitsです。ですから、FractionBitsを1以上にすると整数部分のビット数が減るので最大値が小さくなっていきます。整数部はビットに対して2進数、小数部はビットに対して1m/2^ビット数となります。」


補間処理 <バージョン1.2から可能>
 メッシュデータの補間処理が出来ます。線形補間、Bicubic補間、スプラインキュービック補間をして、データとデータの間の値を作り出し、より細かな地形表現に近づけることができます。ただしあくまで「科学計算」による値ですから、補間データ値が現実と一致する保証はありません。
 倍率は3倍ぐらいがよいようです。作者のBackyさんによれば、4倍がメモリの限界ということです。
 なお、補間処理の場合もファイルサイズは倍数に合わせて大きくなり、ほぼ設定した倍数に近いサイズに肥大化します。
 Bicubic補間=3倍 + FurakutionBits=3 で処理すると、ファイルサイズは標準の6倍ほどになります。


**-- 5mメッシュシーナリーの作成 --**
 (先ずは上記の10mメッシュ作成の場合をご覧の上、下の手順を実行ください。)

 5mメッシュ作りの設定は、10mメッシュの場合と少しだけ手順が異なります。5mメッシュデータに多くの「抜け落ち(データ無し)(−9999)」の部分が含まれることが原因です。
 10mの時のように−9999を0に置換すると、データ無しの地域が標高0mの真っ平らな盆地になってしまいます。
 また、5mメッシュでは河川部分も−9999になっているようで、河川は標高0mの奈落の底に落ち込み、大峡谷のようになって表現されてしまいます。

手順1.ファイルをドラッグ
    10mメッシュ作成の場合と同じです。
手順2.結合処理を指定
    10mメッシュ作成の場合と同じです。
手順3.データ処理の方法を指定
  
    ステップ1で、データを100倍する。
       <−9999についてはアプリが自動的に除外処理するので、気にする必要はない。>
       < −9999については「置換」指定した場合のみ処理される。>
    ステップ2は何もしない。
    ステップ3は何もしない。
    補間処理FractionBitsについては10mメッシュ作成と同じ。

 以上の処理で、値が-9999だった所には何のデータも持たない5mメッシュbglが作成されるので、FSX内では下のレイヤに置いた10mメッシュや38mメッシュのデータで描画され、5mメッシュときれいにつながった地形表現になる。



5m,10m,38mメッシュ使用で予想されるトラブルへの対処法

 FSXデフォルトの日本の標高データは76mメッシュのようです。 このデフォルトのままの上に、より正確な標高メッシュである38m、10m、5m等のメッシュデータを導入して使うと、河川や湖が天井川のように浮き上がって表示されてしまう部分が出てくる可能性があります。実際に、標高変化が大きい辺りの水面では、こういう現象が確認されています。
 こういう場合は、FSXデフォの川・水面標高データを無効にする設定をすれば、この問題は解消されます。ただし欠点もあります。
 以下の拙HPの説明をご覧の上、試してみてください。https://ja9evi.web.fc2.com/GmaxObject/38mesh.html



5mメッシュデータ作成結果のサンプル


 国土地理院から公開されている5mメッシュは、エリアが広くはないのですが、やはり詳細な地形表現が可能になり、山岳地域や海岸では絶大な威力を発揮します。可能な限り5mメッシュデータを使用した方がよいと思われます。

 また、補間処理をすると、スロープ状態の地形に新たな起伏が現れたり、さらにFractionBits=3などと高さ方向の分解能を上げると、シャープな地形を保ちつつデコボコした坂道が滑らかなスロープに表現されたりします。

 しかし、補間と高さ方向の高分解能化は、どの地形でも効果が明瞭に見えるわけではないようで、ファイルサイズの巨大化を考え併せると、思い入れのある地域や、地形をよく知っている地域での低空遊覧飛行の場合などに限定して使用するのがよいように思います。

kanoさん、ochiさん彩雲さんが、デフォルトから3倍補間+FrakutionBits=3等の地形を比較されて、スクリーンショットにされています。
ここに転載しますので、参考にされてください。
お三方には画像使用にご同意いただき、感謝申し上げます。

kanoさん制作の画像







ochiさん制作の画像


彩雲さん制作の画像
一番上の、スプライン補間による階段状の表示はバグとのことで、バージョン1.2では解消されている。


FractionBitsの設定に関して

 上記の設定説明の中で FractionBits を2以上にしたときに、実際の地球上の標高値が処理範囲内に納まり切らなくなる問題の対処法について説明します。

 FractionBits=4 にした場合を例に説明します。
 この場合、高さ方向に1/16mの高分解能のシーナリーを作れますが、処理できる標高値は、-2048m から +2048m までの値になります。そうすると日本の場合でも山岳地帯や富士山では完全に値範囲を超えてしまいます。
 そこで、あらかじめメッシュデータの数値から一定数値Aを引いておいて、その上でJDEM_AUTOで処理し、最後の最後でJDEM_AUTOがAの値を加えてから標高シーナリーファイル(bgl)にコンパイルする方法を採ります。
 Aの値は、FractionBits=4の場合は、2000が適当です。2000を引くということは、-48mから+4048mまで処理できることになりますから、日本の場合、海底地形の標高シーナリーでも作らない限りはこれでいけます。

 手順3.の「結合処理」の部分の処理手順は、以下のようになります。

--** 10mメッシュ作成の場合 **--
 Step1で-9999(=標高データ無しの数値)を0に置換。
     「置換」を選び、左側窓に-9999を入力。右側窓に0を入力。
 Step2で、データ値から2000を引く。
     「数を足す」を選び、左側窓を空白に。右側窓に -2000 を入力。
 Step3で、データ値を100倍する。
    「数を掛ける」を選び、左側の窓は空白にしておき、右側窓に100を入力。


--** 5mメッシュ作成の場合 **--

 Step1で、データ値から2000を引く。
     「数を足す」を選び、左側窓を空白に。右側窓に -2000 を入力。
      <-9999の値については、「置換」処理以外は無視されるので気にしなくてよい。>
 Step2で、データ値を100倍する。
    「数を掛ける」を選び、左側の窓は空白にしておき、右側窓に100を入力。
 Step3は何もしない。

 設定した-2000については、アプリが自動的にBaceValue値として「戻し」処理をやってくれるので気にしなくてよい。



ホ−ムページに戻る(Go to HOMEpage)