開発製作記事

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

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

 物理的な紙図面や、写真フィルムが二次元情報であり、模型やホログラフィーが三次元情報であるのに対して、 デジタル化されたテキストや画像や立体(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.上位の階層構造  コピーされたオブジェクトが整然と、あるいはランダムに配置されているよう な場合  いわゆるレイヤーは、比較的単純な階層構造ですが、このレベルにあるいくつ かのフォーマットは、  三次元図形を記述するファイルは以下のようなデータ要素を有している
1.頂点座標 いわゆるDEMデータなどはこのレベルしかない
2.面または線など 初期のCADはこのレベルを基本としている
3.一塊のオブジェクト たとえば、多くの地物は、ソリッドと呼ばれる、閉多面体のまとまりである。特定目的のための独自フォーマットのデータはこの構造をもっている。
4.上位の階層構造
@コピーされたオブジェクトが整然と、あるいはランダムに配置されているような場合
A住戸(内部構成)−建物−敷地−地区−都市全体といった空間的階層
Bいわゆるレイヤー
上位の階層構造まで有するいくつかのフォーマットは、 一つの言語と言えるような複雑な構造を持っている。

0.メタ情報 (分散ファイルにおけるDOS等の階層構造等) (ファイル名フルパス、タイムスタンプ等) (ヘッダー部分に書き込まれた各種情報) (座標系、位置精度など) →本体に含まれない外的情報を、添付して保存する定義ファイルの中に含めるこ とも可能と思います。 1.頂点座標(の表記方法) (テクスチャ座標、法線、カラー等があれば含める) (無効領域、Unknown等の扱い、精度レベルに対して意味のない下位の桁の数値 のコンバータ側での扱い) 2.面・線(ポリゴン・ライン) 3.緬・綾・縫(パラメトリックな曲面、スプライン面、曲った縫合線) 4.ソリッド、オブジェクト等、意味ある形状のまとまり (これらに貼りついた属性情報) 5.上位の階層構造、レイヤー構成、時間変化等 6.光源、視点等の環境情報 7.注釈、吹き出し、補助線・寸法線、音声、触覚、臭気・・・・ 8.外部参照オブジェクト(テクスチャ、動的機能、参照ファイルURL、フォ ント・・・) コンバータは、これらのデータを解析して、以下のような情報を取り出している。
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の定義ファイルに不変性を付与できる。

RAIDの換装について

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