開発製作記事

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

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


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

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

CAG、GIS系のデータ形式は、ＸＹプロッターを駆動して製図を自動化するために当初開発された。従って、二次元的に、ペンの移動(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 (出力のみ)

三次元図形を記述するファイルは以下のようなデータ要素を有している １．頂点座標 　いわゆるＤＥＭデータなどはこのレベルしかありません ２．面または線など 　初期のＣＡＤはこのレベルを基本としています ３．一塊のオブジェクト 　特定目的のための独自フォーマットのデータはこの構造をもっています ４．上位の階層構造 　コピーされたオブジェクトが整然と、あるいはランダムに配置されているよう な場合 　いわゆるレイヤーは、比較的単純な階層構造ですが、このレベルにあるいくつ かのフォーマットは、 　三次元図形を記述するファイルは以下のようなデータ要素を有している
１．頂点座標 いわゆるＤＥＭデータなどはこのレベルしかない
２．面または線など 初期のＣＡＤはこのレベルを基本としている
３．一塊のオブジェクト たとえば、多くの地物は、ソリッドと呼ばれる、閉多面体のまとまりである。特定目的のための独自フォーマットのデータはこの構造をもっている。
４．上位の階層構造
�@コピーされたオブジェクトが整然と、あるいはランダムに配置されているような場合
�A住戸（内部構成）−建物−敷地−地区−都市全体といった空間的階層
�Bいわゆるレイヤー
上位の階層構造まで有するいくつかのフォーマットは、 一つの言語と言えるような複雑な構造を持っている。

０．メタ情報 （分散ファイルにおけるＤＯＳ等の階層構造等） （ファイル名フルパス、タイムスタンプ等） （ヘッダー部分に書き込まれた各種情報） （座標系、位置精度など） →本体に含まれない外的情報を、添付して保存する定義ファイルの中に含めるこ とも可能と思います。 １．頂点座標（の表記方法） （テクスチャ座標、法線、カラー等があれば含める） （無効領域、Unknown等の扱い、精度レベルに対して意味のない下位の桁の数値 のコンバータ側での扱い） ２．面・線（ポリゴン・ライン） ３．緬・綾・縫（パラメトリックな曲面、スプライン面、曲った縫合線） ４．ソリッド、オブジェクト等、意味ある形状のまとまり （これらに貼りついた属性情報） ５．上位の階層構造、レイヤー構成、時間変化等 ６．光源、視点等の環境情報 ７．注釈、吹き出し、補助線・寸法線、音声、触覚、臭気・・・・ ８．外部参照オブジェクト（テクスチャ、動的機能、参照ファイルＵＲＬ、フォ ント・・・） コンバータは、これらのデータを解析して、以下のような情報を取り出している。
０．メタ情報
（分散ファイルにおけるＤＯＳ等の階層構造等）
（ファイル名フルパス、タイムスタンプ等）
（ヘッダー部分に書き込まれた各種情報）
（座標系、位置精度など）
（本体に含まれない外的情報を、添付して保存する定義ファイルの中に含めることも可能）
１．頂点座標
（の表記方法）
（テクスチャ座標、法線、カラー等があれば含める）
（無効領域、Unknown等の扱い、精度レベルに対して意味のない下位の桁の数値のコンバータ側での扱い）
２．面・線（ポリゴン・ライン）
３．緬・綾・縫（パラメトリックな曲面、スプライン面、曲った縫合線）
４．ソリッド、オブジェクト等、意味ある形状のまとまり（これらに貼りついた属性情報）
５．上位の階層構造、レイヤー構成、時間変化等
６．光源、視点等の環境情報
７．注釈、吹き出し、補助線・寸法線、音声、触覚、臭気・・・・
８．外部参照オブジェクト（テクスチャ、動的機能、参照ファイルＵＲＬ、フォント・・・） →参照の上、将来的にアクセスが保証されないものは現物を添付する方向

(1) ファイル形式（ＤＸＦ）
(2) 解析処理のロジック
(3) 解析を実装したプログラム
(4) 操作方法その他
(5)形式に関する所感

　あるコンピュータ上で、異なるハード、ＯＳのために作られたプログラムを実行し、 　データを入出力する技術は仮想化技術と呼ばれる。
　例えば現在、Windows上で、かつてのN88BASICで書かれたプログラムを実行するためには、�@T98-NEXT というハードウェアのエミュレータを実行し、この上でＯＳとプログラムを実行する方法、�AN88互換BASIC for Windows95というN88BASICインタプリタ実行環境のエミュレータを使用する方法などがある。しかし、これのプラットフォームとなっているWindowsマシンが過去のものとなった場合には、エミュレーションもそのままでは実行できなくなる。
これを一般化し、様々な時代のハード、ＯＳを仮想化した博物館マシンがあれば、任意のハード、ＯＳ上（たとえば1982年のOASIS(専用ワープロ）で作成した文書ファイルを修正して印刷することもできるであろう。更に、このような博物館マシンを仕様としてＰＦ定義し、それを不変化することができれば、それを前提として各時代のハード、ＯＳの定義ファイルに不変性を付与できる。

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