開発製作記事

データ処理のためのソフトウェア開発、及び保存装置に関連した製作に向けた検討結果を解説します。

結節点としてのビットストリーム

 物理的な紙図面や、写真フィルムが二次元情報であり、模型やホログラフィーが三次元情報であるのに対して、 デジタル化されたテキストや画像や立体(CTスキャン画像など)は、メモリ上での記憶、物理的なメディアへの保存や通信においては一次元のデジタルデータ(ストリーム)として処理されている。 コンピュータが扱う「三次元データ」と言われるものも、その殆どは、ストリーム型のデータであり、この意味では三次元空間を表現する一次元データである。 ヒストリーのコーナーに挙げた、パンチカードや各種磁気ディスクなどは、全て、 ビットストリームを保存するための物理的媒体と見ることができる。
 従って、永久保存という課題に対する解決は、基本的に
1.ビットストリームを永久保存する物理的なメディア、読み書き装置、ファイルシステム等
2.三次元形状・空間をビットストリームとして表現するファイル・フォーマット
の二つに分解して考えることができる。更には、第三の道として、
3.二次元以上の記録媒体
を単独で、あるいは1、2と併用して補助的に用いることが考えられる。

 例えば、過去に作成されたある三次元データが、8インチフロッピーに格納されていて、 これを解読して利用しなければならないとする。その場合、二次元的に磁化された円盤から、 トラック、セクターを識別し、更にその中に定義された ファイルアロケーションテーブルを解析し、飛び飛びに散在するセクターをつないで一つのファイル(ビットストリーム)を 復原するまでが、上記の結節点までの第一段階である。次に、このビットストリームから、三次元形状やその属性に係る情報を 復原することが第二段階となる。
 実際に、かつて広く用いられていた、特段の保護策が講じられていない記録であっても、古くなると「解読すべき暗号」としての性格を帯びる。従って、この研究開発のタスクは、物理的媒体や、それを再生する装置や、データ形式に関する情報が既に失われた後の遠い将来において、 「確実に解読できる暗号」とは何か、更には「最も解読しやすい暗号」は何か、という問いに答えることである。


ファイルが、同一メディア上の別ファイルを参照しているような場合には、複数のビットストリームを相互参照関係を含めて取り出す必要がある。
このためには、未使用領域も含めたメディア上の全ての記憶域をビットストリームとして設定し、DOSが規定するディレクトリ構成を含めてデータ形式として扱う方が有効かも知れない。

仮想コンバータ構想について

 同時代におけるコミュニケーションを可能とするために、ビットストリームとしてのデータ形式を標準化する試みは多く行われ、成果を挙げている。 しかし、技術進歩の結果として、常に新たなデータ形式が開発され普及することにより、データ形式の陳腐化が発生し、時代を超えたデータの利用を困難にする。 このため、現在すでに、利用が困難となった過去のデータ形式も生じてきている。
 同時代において、異なるデータ形式で記録されたビットストリームを利用するためには、利用できるデータ形式に変換するためのコンバータを利用する。しかし、実体としてのコンバータ実行形式は、具体的なハードウェアとOSの上で動作するものであるから、時流的存在であって、マシンやOSの変化に対応してアップデートしない限り、過去のデータを対象としたコンバータ自体も、いずれ過去のものとなり利用できなくなる。
しかし、コンバータの機能を厳密に定義する資料がデータそのものに添付されていれば、データが必要となった時点でコンバータを作成することが可能である。
 この考え方を一歩進めて、「プログラム可能な仮想コンバータ」+「データ形式定義ファイル」により任意のコンバータが利用できる作業環境が実現できれば、コンバータを実装するために必要なコーディング作業は大幅に軽減される。 このデータ形式定義ファイルは、たとえばゼロベースからC言語で書かれたコンバータのソースコードよりも、大幅に簡潔化することが期待できる。
 具体的な変換のためには、まず仮想コンバータの仕様書に従った仮想コンバータの一つの実装(実行形式)を時流のハード・OSの上で実現する。これは汎用性が高いので、 社会的に成立するであろう。
 もし、利用したい変換元のデータに、「データ形式定義ファイル」が添付されていれば、これを、仮想コンバータの一つの実行形式に予めインプットすることにより、古いデータ本体の読み込みができるようになる。
次に、出力したい時流形式の「データ形式定義ファイル」を仮想コンバータに読み込ませることにより、求める形式によるデータの書き出しと利用が可能となる。

仮想マシン:ハードウェアをエミュレートする最もコアな部分は、異なるCPUのエミュレーションである。メジャーなマシン相互のエミュレーションの他に、例えばJAVA仮想マシンをエミュレートする機能を各メジャーCPUないしOS上で実現し、このマシンを共有することによりソフト資産の共有化・汎用化を行う、という試みが行われている。

CAD、GIS、CG系の各種データ形式について

CAG、GIS系のデータ形式は、XYプロッターを駆動して製図を自動化するために当初開発された。従って、二次元的に、ペンの移動(move)とライン引き(draw)の動きを記録するものを出発点としている。 MiniCAD形式(Vector Worksの前身)は、まさにMoveTo, LineToというコマンドを有している。その後デジタルデータそのものが流通・交換されるようになり、意味あるまとまりが記述できるような形式に発展した。
三次元データに関しては、射影変換をかけてから画面表示するものが多いため、二次元から拡張されたものを除くと、最初から意味あるまとまりを有するものが多い。
これまで、景観シミュレーションにデータを利用するためにファイル・コンバータが作成されたデータ形式には、以下のものがある。
.dxf (AutoCAD)
.shp (ArcGIS)
.mem, .lem (数値地図)
.3ddb (三次元データベース)
.mc, .mcd(MiniCad, VectorWorksの前身)
.GeoTif (衛星画像等)
.wrl (VRML)
.ttf(フォント)
.scn (LSSS)
.geo (LSSG)
.dat (SimFire延焼シミュレーション形式)
.P21 (SXF)
.330 (建築確認申請)

また、二次元ではあるが、テクスチャや背景等の画像を記録する以下のファイル形式に関して、ファイル入出力機能が作成されている。
.tif, .tiff
.jpg, .jpeg
.bmp
.tif, .tiff
.png
.sgi .rgb
.gif (本形式に関しては非公開)
.avi (出力のみ)

三次元図形を記述するファイルは以下のようなデータ要素を有している。  
1.頂点座標 いわゆるDEMデータなどはこのレベルしかない
2.面または線など 初期のCADはこのレベルを基本としている
3.一塊のオブジェクト たとえば、多くの地物は、ソリッドと呼ばれる、閉多面体のまとまりである。特定目的のための独自フォーマットのデータはこの構造をもっている。
4.上位の階層構造
@コピーされたオブジェクトが整然と、あるいはランダムに配置されているような場合
A住戸(内部構成)−建物−敷地−地区−都市全体といった空間的階層
Bいわゆるレイヤー
上位の階層構造まで有するいくつかのフォーマットは、 一つの言語と言えるような複雑な構造を持っている。
これまでに作成したコンバータは、これらのデータを解析して、以下のような情報を取り出している。  
0.メタ情報
(分散ファイルにおけるDOS等の階層構造等)
(ファイル名フルパス、タイムスタンプ等)
(ヘッダー部分に書き込まれた各種情報)
(座標系、位置精度など)
(本体に含まれない外的情報を、添付して保存する定義ファイルの中に含めることも可能)
1.頂点座標
(の表記方法)
(テクスチャ座標、法線、カラー等があれば含める)
(無効領域、Unknown等の扱い、精度レベルに対して意味のない下位の桁の数値のコンバータ側での扱い)
2.面・線(ポリゴン・ライン)
3.緬・綾・縫(パラメトリックな曲面、スプライン面、曲った縫合線)
4.ソリッド、オブジェクト等、意味ある形状のまとまり(これらに貼りついた属性情報)
5.上位の階層構造、レイヤー構成、時間変化等
6.光源、視点等の環境情報
7.注釈、吹き出し、補助線・寸法線、音声、触覚、臭気・・・・
8.外部参照オブジェクト(テクスチャ、動的機能、参照ファイルURL、フォント・・・) →参照の上、将来的にアクセスが保証されないものは現物を添付する方向
例:3D Solid 形式の変換について
(1) ファイル形式(DXF)
DXF形式は、普及しているAutoCADの外部ファイル形式の一つであるが、テキストベースであり、初期のバージョンにおいて、ソフトウェアの解説書に形式の説明があったことから、様々なCADの間でのデータ交換のためのデファクト・スタンダードとして用いられてきている。
1995年ころから導入された3D Solid形式は、テキストベースではあるが、コード変換された文字により構成されている。これは、自由曲面から構成される閉じた立体を記述することができる複雑なデータ形式である。
3D Solid形式の一行は、Opecode: [整数] Operand: [文字列]を単位としている。1行で記述が完結する場合には、行末が'#'である。そうでない場合には、次の行に記述が継続する。
body コマンドを起点として、#を区切りとする行の単位に通し番号を与え、これに対する参照が行われる。この参照は、$[整数]の形で記述される。
(2) 解析処理のロジック
景観シミュレータの貿易コンバータのDXF2LSSに、以下の機能を追加することにより変換処理を実現した。
@DXFファイルを処理する中で、3D-Solid形式の部分を検出した場合、その部分の終了までを、可読な形に変換したテキストファイルとして外部ファイルに出力し、その間をスキップして変換処理を続行する。
A一つのファイルを解析して、立体を復元し、LSS-G形式で出力する機能を有する、3DSolid.c を作成し、コンバータに追加。
Bテスト・デバッグが進んだ段階で、この機能を、貿易コンバータに組み込み、一体的に動作させる。
なお、現段階(100812)では、この機能は未完成ではあるが、多くのサンプルに関して一定の形状を出力するに至っている。
(3) 解析を実装したプログラム
3dSolid.c は以下の機能を有している:
@一つのテキスト・ファイルを開き、ポインタで繋がれた緬をトレースする。 outface(iface);
A個々の緬に関して、縁(loop)のリストを作成する。
B縁を構成する縫(coedge-edge)のリストを作成する。
C個々の緬のタイプ別に形状生成する。
平面、円錐面、スプライン曲面、球面、トーラス面
(4) 操作方法その他
最終的には、通常のDXFファイルと同様に変換操作を行う。
(5)形式に関する所感
・3Dソリッドのデータ構造は、基本的には、サーフェス・モデルにおける面を、パラメトリックな面(仮に「緬」と呼ぶ)に拡張したものと理解することができる。立体は、ポインタで繋がれた、緬により包含される。緬は緬の属性(平面か、円錐面か、球面か、トーラス面か、スプライン面か、それぞれについてのパラメータ)と、縁を構成する辺(ポインタで繋がれてループを形成する)により構成される。
・縁は、複数のループから成る。例えば、円柱形の場合には、側の緬(円錐)は、上と下に二つのループを持つ。
・一つのループは、複数の辺から構成される。
・スプライン緬とスプライン緬の交線などは、更にスプライン曲線として記述されることになる。
・スプライン曲線は、グラフィックス表示において、視点からの距離に応じた精度でポリゴンに分割するような処理には適しているが、このようなスプライン近似においては、交線の形状は厳密な定義にはなっていない。従って、幾何学演算を行うためには、あくまでも近似的な性格を帯びる。

いわゆる、仮想化技術について

 あるコンピュータ上で、異なるハード、OSのために作られたプログラムを実行し、データを入出力する技術は仮想化技術と呼ばれる。
 例えば現在、Windows上で、かつてのN88BASICで書かれたプログラムを実行するためには、@T98-NEXT というハードウェアのエミュレータを実行し、この上でOSとプログラムを実行する方法、AN88互換BASIC for Windows95というN88BASICインタプリタ実行環境のエミュレータを使用する方法などがある。しかし、これのプラットフォームとなっているWindowsマシンが過去のものとなった場合には、エミュレーションもそのままでは実行できなくなる。
これを一般化し、様々な時代のハード、OSを仮想化した博物館マシンがあれば、任意のハード、OSが再現でき、たとえば1982年のOASIS(専用ワープロ)で作成した文書ファイルを修正して印刷することもできるであろう。更に、このような博物館マシンを仕様としてPF定義し、それを不変化することができれば、それを前提として各時代のハード、OSの定義ファイルに不変性を付与できる。
ソフトプロセッサ
いわゆるプログラマブルロジックデバイス(PLD)が発達した結果、これらの上にハードロジックをプログラムすることにより、マイクロプロセッサを実装することができるようになった。
例えば、1chipMSXプロジェクト(www.msx.d4e.co.jp)では、生産終了となったパソコンのシステム全体をFPGAチップの上に再現したものである。(*Field Programmable Gate Arrayの略)

RAIDの換装について

 記憶のためのハードウェアとして、HDDは最近急速に成長している。バックアップのための媒体を見出すのが困難なほど高密度・低価格化してきた。 クラッシュのリスクを回避するために、古くからRAIDによる危険分散が行われている。
例えば2台をミラーリングする場合、1台のリスクが十分小さく、10−nレベルであるとすると、RAID1で2台接続すれば、これを10−2nレベルとすることができる。 しかし、現実には、色々と制約がある。
@2台のHDDは同じ製品であることが望ましい。 しかし、クラッシュするのは数年後であり、その時点では、既により大容量・高速のドライブが主流となっており、同型を入手することが困難である。
A容量が異なるドライブでも、RAID1を組むことはできるが、ペアの記憶容量は、容量の小さな方のドライブに合わせることとなり、新しい交換部品の性能が生かせない。
B全般に、最初にRAID1を設定する場合の操作マニュアルは充実しているが、クラッシュした後に、換装する手順の解説は不親切である。換装作業に失敗すると、データが失われてしまう。1台となった状態でバックアップを取り、まだ壊れていないドライブも捨てて、新たなRAIDペアに全交換するのが安全であるが、無駄が多い。
C容量の異なるRAIDペアの内、小さい方のHDDが次にクラッシュして、より大きなドライブに換装しても、ペアとしての容量は、昔初期設定したもの容量から増やせない
といったユーザー側にとっての問題がある。上記のような問題を解決することは技術的には難しくないように思われる。この分野の傾向として、長期的な安心のための初期設定(システムを選択・購入する段階)に関しては詳しいが、将来、実際にディスクが故障して、その特長を生かそうとした時には、不親切である。

二村の射影と景観シミュレータの外部関数について

 二村良彦(1971)は、部分評価に着目して、コンパイラ・コンパイラの概念を整理した。 <Partial Evaluation of Computation Process-an Approach to a Compiler-Compiler-, "Systems, Computers, Controls" Vol.2, No.5, 1971 pp45-50) >
これによると、定数C、ランタイム・データRを引数とするプログラム
  π(C,R)
  は、コンパイラαにより、
  α(π,C)
  という実行形式に変換でき、α(π, C) (R)は、引数がランタイム・データのみとなるため、計算過程が簡略化することが期待できる(例えば、Y=1+C+R というプログラムは、定数Cが2であれば、Y=3+Rの形に変換できる)。
 インタープリタ int 上で動くソースコードをS,ランタイムデータをRとすると、Sは定数、Rはランタイムと見て、
  int(S,R)
 は、同様にして、α(int,S) (R) という、Rのみを引数とする実行形式に変換することができる(第一射影)。
 更に、α(int, S)は、α(α,int)(S)の形に変換でき、α(α,int)は、ソースコードを実行形式に変換するコンパイラである(第二射影)。
 更に、α(α, int)は、α(α、α)(int)の形に変換でき、このα(α,α)は、インタプリタをコンパイラに変換するコンパイラ・コンパイラである(第三射影)。

景観シミュレータにおける外部関数は、これと同じような動作をしている。
G=FILE(C);は、固定的な形状ファイルを参照するのみであるのに対して、
G=FILE(C, R);は、実行形式C.exe を起動し、ランタイム値Rをこれに渡す。
この時、C.exe は、引数Rをパラメータとして補完し、完全(固定的)な形状データを返す。従って、上記のα(π,C)に相当する機能である。
実用的には、多くのファイルコンバータがこの形式で実装されている。
G=FILE(コンバータ名,変換元ファイル名);
(例)G=FILE(FIRE2LSS, BUILDINGS.geo);
もし、インタープリタ interpret.exe を外部関数として実装し(まだない)、この上で動作するスクリプトによりコンバータが記述できれば、同じ変換を、
 G=FILE(INTERPRET, SCRIPT, 変換元ファイル名);
 により得ることができる(第一射影)。
 COMPILE.exe が、インタプリタと同じ言語のスクリプトを引数として実行形式を生成し、これにランタイム引数を渡して実行させる機能を有するとすれば、同じ変換を、
 G=FILE(COMPILE, SCRIPT, 変換元ファイル名);
 により同じ結果を得ることができる(第二射影)。
更に、コンパイラ・コンパイラCC(cc.exe)が、スクリプトのための文法規則GRAMMARからコンパイラを生成してそれを実行するとすれば、
 G=FILE(CC, GRAMMAR, SCRIPT, 変換元ファイル名);
により同じ結果を得ることができる(第三射影)。
 このGRAMMARを永久不変の約束事として定義しておき、その上で変換元ファイルにSCRIPTを添付したものを保存しておけば、ハード、OS、アプリの栄枯盛衰を超えて、データの可読性を維持することができる。
 

三次元データの分類について

三次元データは、様々観点からの分類が可能であるが、まず立体を表現する幾何学的な手段として、次の3種類に大きく分類することができる。
点の集合体で表現する方法
 物体の表面上に存在する点により表現する。最もよく使用されるのは地形を表現するDEMデータである。格子状に定義された点の高さ値だけを羅列する方法は、コンパクトに形状を記述することができるため、国土地理院が発行している数値地図標高データなどに用いられている。
 最近では、レーザースキャナーによる形状計測が普及したため、厖大な点(X,Y,Z座標)を羅列したデータ(ドット・クラウド)が作成されている。
線分の集合体で表現する方法
 物体の表面上に存在する線分により表現する。代表的なものに、等高線で地形を表現した地形図がある。これは、高さ方向に一定間隔で配置された平面により地形を切断したときの断面図の集合体である。最近医療に使用されるCTスキャンやMNRなどの画像は、人体を一定間隔の垂直面で切断した時の断面図の集合体である。
面の集合体で表現する方法
 物体の表面を構成する面を、近似的な多角形のタイル(ポリゴン)に分割し、この集合体として立体を表現する。この時、タイルが隙間なく物体の表面を蔽っている場合には、閉多面体として、その体積を計算することができる(ソリッド・モデル)。
 特殊な場合として、タイルを三角形だけに限定したようなデータ形式も用いられている。

座標系ついて

GISデータを扱う場合には、地球に対する絶対的な位置を明らかにするために、座標値の原点が地表面に定義されている。しかし座標系にはいくつかの異なる方法が混在しており、歴史的にも変遷していることから、座標値の意味を明らかにした上で使用しないと、位置ずれを起こしたりする。
国家座標系
 日本の国土全体を19のエリアに分割し、それぞれに平面直角座標系を適用したものである。
世界座標系
 2002年から、国際的な座標系に合わせて修正を加えたもので、 19のエリア分割は変わらないが、座標値が400m程度変化した。
UTM
 インドネシアなどで用いられている、メルカトール座標系である。南極をY座標の原点としている。
緯度経度
 GPSで得られる位置情報は緯度経度である。近年では建築確認申請を行う際に、敷地の位置を緯度経度で表記する方法が採られている。GoogleEarth等で位置合わせを行うために使用されている。
地殻変動の影響
 日本付近においては、地殻変動が活発であるために、基準点を始め、地面が流動している。このため、地物の座標値は恒久的に一定ではなく、GPSで計測されるような緯度経度は変化していく。
 これに対して、基準点(局所座標系の原点)を適宜補正すれば、同じ座標値を用いて、近似的に場所を特定することができる。
 東日本大震災に際しては、東北地方の東海岸が約5m、西海岸が約4m東に移動し、差し引き4mほど東北地方の東西幅が広がった。このため、所々で活断層が動き、局地的な地震を発生させた。また、大震災後も長い期間にわたり、土地が移動を続けており、岩手県の東海岸では2か月で40cm程度東に移動している(余効変動)。  地理院では8月を目途に、基準点の新しい位置を確定する予定であるという。
Last updated : 2011/5/26 18:24:25
NILIM