開発製作記事
データ処理のためのソフトウェア開発、及び保存装置に関連した製作に向けた検討結果を解説します。
結節点としてのビットストリーム
従って、永久保存という課題に対する解決は、基本的に
１．ビットストリームを永久保存する物理的なメディア、読み書き装置、ファイルシステム等
２．三次元形状・空間をビットストリームとして表現するファイル・フォーマット
の二つに分解して考えることができる。更には、第三の道として、
３．二次元以上の記録媒体
を単独で、あるいは１、２と併用して補助的に用いることが考えられる。
例えば、過去に作成されたある三次元データが、８インチフロッピーに格納されていて、 これを解読して利用しなければならないとする。その場合、二次元的に磁化された円盤から、 トラック、セクターを識別し、更にその中に定義された ファイルアロケーションテーブルを解析し、飛び飛びに散在するセクターをつないで一つのファイル（ビットストリーム）を 復原するまでが、上記の結節点までの第一段階である。次に、このビットストリームから、三次元形状やその属性に係る情報を 復原することが第二段階となる。
実際に、かつて広く用いられていた、特段の保護策が講じられていない記録であっても、古くなると「解読すべき暗号」としての性格を帯びる。従って、この研究開発のタスクは、物理的媒体や、それを再生する装置や、データ形式に関する情報が既に失われた後の遠い将来において、 「確実に解読できる暗号」とは何か、更には「最も解読しやすい暗号」は何か、という問いに答えることである。
ファイルが、同一メディア上の別ファイルを参照しているような場合には、複数のビットストリームを相互参照関係を含めて取り出す必要がある。
このためには、未使用領域も含めたメディア上の全ての記憶域をビットストリームとして設定し、ＤＯＳが規定するディレクトリ構成を含めてデータ形式として扱う方が有効かも知れない。
仮想コンバータ構想について
同時代において、異なるデータ形式で記録されたビットストリームを利用するためには、利用できるデータ形式に変換するためのコンバータを利用する。しかし、実体としてのコンバータ実行形式は、具体的なハードウェアとOSの上で動作するものであるから、時流的存在であって、マシンやOSの変化に対応してアップデートしない限り、過去のデータを対象としたコンバータ自体も、いずれ過去のものとなり利用できなくなる。
しかし、コンバータの機能を厳密に定義する資料がデータそのものに添付されていれば、データが必要となった時点でコンバータを作成することが可能である。
この考え方を一歩進めて、「プログラム可能な仮想コンバータ」＋「データ形式定義ファイル」により任意のコンバータが利用できる作業環境が実現できれば、コンバータを実装するために必要なコーディング作業は大幅に軽減される。 このデータ形式定義ファイルは、たとえばゼロベースからC言語で書かれたコンバータのソースコードよりも、大幅に簡潔化することが期待できる。
具体的な変換のためには、まず仮想コンバータの仕様書に従った仮想コンバータの一つの実装（実行形式）を時流のハード・OSの上で実現する。これは汎用性が高いので、 社会的に成立するであろう。
もし、利用したい変換元のデータに、「データ形式定義ファイル」が添付されていれば、これを、仮想コンバータの一つの実行形式に予めインプットすることにより、古いデータ本体の読み込みができるようになる。
次に、出力したい時流形式の「データ形式定義ファイル」を仮想コンバータに読み込ませることにより、求める形式によるデータの書き出しと利用が可能となる。
CAD、GIS、CG系の各種データ形式について
三次元データに関しては、射影変換をかけてから画面表示するものが多いため、二次元から拡張されたものを除くと、最初から意味あるまとまりを有するものが多い。
これまで、景観シミュレーションにデータを利用するためにファイル・コンバータが作成されたデータ形式には、以下のものがある。
|
.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 (出力のみ) |
２．面または線など 初期のＣＡＤはこのレベルを基本としている
３．一塊のオブジェクト たとえば、多くの地物は、ソリッドと呼ばれる、閉多面体のまとまりである。特定目的のための独自フォーマットのデータはこの構造をもっている。
４．上位の階層構造
①コピーされたオブジェクトが整然と、あるいはランダムに配置されているような場合
②住戸（内部構成）－建物－敷地－地区－都市全体といった空間的階層
③いわゆるレイヤー
これまでに作成したコンバータは、これらのデータを解析して、以下のような情報を取り出している。
（分散ファイルにおけるＤＯＳ等の階層構造等）
（ファイル名フルパス、タイムスタンプ等）
（ヘッダー部分に書き込まれた各種情報）
（座標系、位置精度など）
（本体に含まれない外的情報を、添付して保存する定義ファイルの中に含めることも可能）
１．頂点座標
（の表記方法）
（テクスチャ座標、法線、カラー等があれば含める）
（無効領域、Unknown等の扱い、精度レベルに対して意味のない下位の桁の数値のコンバータ側での扱い）
２．面・線（ポリゴン・ライン）
３．緬・綾・縫（パラメトリックな曲面、スプライン面、曲った縫合線）
４．ソリッド、オブジェクト等、意味ある形状のまとまり（これらに貼りついた属性情報）
５．上位の階層構造、レイヤー構成、時間変化等
６．光源、視点等の環境情報
７．注釈、吹き出し、補助線・寸法線、音声、触覚、臭気・・・・
８．外部参照オブジェクト（テクスチャ、動的機能、参照ファイルＵＲＬ、フォント・・・） →参照の上、将来的にアクセスが保証されないものは現物を添付する方向
例：3D Solid 形式の変換について
1995年ころから導入された3D Solid形式は、テキストベースではあるが、コード変換された文字により構成されている。これは、自由曲面から構成される閉じた立体を記述することができる複雑なデータ形式である。
3D Solid形式の一行は、Opecode: [整数] Operand: [文字列]を単位としている。１行で記述が完結する場合には、行末が'＃'である。そうでない場合には、次の行に記述が継続する。
body コマンドを起点として、#を区切りとする行の単位に通し番号を与え、これに対する参照が行われる。この参照は、$[整数]の形で記述される。
①DXFファイルを処理する中で、3D-Solid形式の部分を検出した場合、その部分の終了までを、可読な形に変換したテキストファイルとして外部ファイルに出力し、その間をスキップして変換処理を続行する。
②一つのファイルを解析して、立体を復元し、LSS-G形式で出力する機能を有する、3DSolid.c を作成し、コンバータに追加。
③テスト・デバッグが進んだ段階で、この機能を、貿易コンバータに組み込み、一体的に動作させる。
なお、現段階(100812)では、この機能は未完成ではあるが、多くのサンプルに関して一定の形状を出力するに至っている。
①一つのテキスト・ファイルを開き、ポインタで繋がれた緬をトレースする。 outface(iface);
②個々の緬に関して、縁(loop)のリストを作成する。
③縁を構成する縫(coedge-edge)のリストを作成する。
④個々の緬のタイプ別に形状生成する。
平面、円錐面、スプライン曲面、球面、トーラス面
・縁は、複数のループから成る。例えば、円柱形の場合には、側の緬（円錐）は、上と下に二つのループを持つ。
・一つのループは、複数の辺から構成される。
・スプライン緬とスプライン緬の交線などは、更にスプライン曲線として記述されることになる。
・スプライン曲線は、グラフィックス表示において、視点からの距離に応じた精度でポリゴンに分割するような処理には適しているが、このようなスプライン近似においては、交線の形状は厳密な定義にはなっていない。従って、幾何学演算を行うためには、あくまでも近似的な性格を帯びる。
三次元データの分類について
点の集合体で表現する方法
物体の表面上に存在する点により表現する。最もよく使用されるのは地形を表現するDEMデータである。格子状に定義された点の高さ値だけを羅列する方法は、コンパクトに形状を記述することができるため、国土地理院が発行している数値地図標高データなどに用いられている。最近では、レーザースキャナーによる形状計測が普及したため、厖大な点（X,Y,Z座標）を羅列したデータ（ドット・クラウド）が作成されている。
線分の集合体で表現する方法
物体の表面上に存在する線分により表現する。代表的なものに、等高線で地形を表現した地形図がある。これは、高さ方向に一定間隔で配置された平面により地形を切断したときの断面図の集合体である。最近医療に使用されるCTスキャンやMNRなどの画像は、人体を一定間隔の垂直面で切断した時の断面図の集合体である。面の集合体で表現する方法
物体の表面を構成する面を、近似的な多角形のタイル（ポリゴン）に分割し、この集合体として立体を表現する。この時、タイルが隙間なく物体の表面を蔽っている場合には、閉多面体として、その体積を計算することができる（ソリッド・モデル）。特殊な場合として、タイルを三角形だけに限定したようなデータ形式も用いられている。
様々な三次元データのファイル形式
|
Extension |
Name |
|
3dm |
Rhino |
|
3dmf |
Quickdraw 3D |
|
3ds |
3D Studio |
|
3dxml |
3D XML |
|
ac |
AC3D |
|
arc |
I-DEAS |
|
ase |
ASCII Scene Export |
|
asm |
Pro/Engineer, Solid Edge, SolidWorks |
|
atr |
Lightscape Material |
|
bdl |
OneSpace Designer |
|
blend |
Blender |
|
blk |
Lightscape Blocks |
|
br4 |
Bryce |
|
c4d |
Cinema 4D |
|
cab |
TrueSpace |
|
cadds |
CADDS |
|
catdrawing, catshape |
CATIA V5 |
|
catpart, catproduct |
CATIA V5 |
|
cgr |
CATIA Drawing |
|
chr |
3Ds Max Characters |
|
dae |
AutoDesk Collada |
|
ddf |
Data Descriptive File |
|
dte |
DTED, National Geospatial-Intelligence Agency (NGA)'s Digital Terrain Elevation Data |
|
dem |
Digital Elevation Models |
|
df |
LightScape Parameter |
|
dlv |
CATIA V4 |
|
drf |
VIZ Reader |
|
dwf |
AutoDesk Composer Design Web Format |
|
dwg |
Legacy AutoCAD Drawing |
|
dws |
AutoCAD Standards |
|
dwt |
AutoCAD Drawing Template |
|
dxf |
AutoCAD Drawing Exchange Format |
|
e00 |
TIGER/Line Arc Interchange format |
|
eim |
Electric Image |
|
exp |
CATIA V4 |
|
fac |
Electric Image |
|
fbx |
AutoDesk Kaydara FBX |
|
fbl |
CADfix Log File |
|
fig |
xfig |
|
flt |
Flight Studio OpenFlight |
|
fmz |
FormZ Project File |
|
ft#, rt# |
TIGER, Topologically Integrated Geographic Encoding and Referencing |
|
gmax |
AutoDesk Game Creator |
|
gml |
OpenGIS Geography Markup Language |
|
gts |
GNU Triangulated Surface |
|
hrc |
SoftImage |
|
htr |
Motion Analysis HTR file |
|
iam |
AutoDesk Inventor |
|
ifc |
Industry Foundation Classes |
|
ige, igs, iges |
Initial 2D/3D Graphics Exchange Specification |
|
ini |
POV-Ray animation script |
|
iob |
3D Object TDDDB Format |
|
ipt, iam |
AutoDesk Inventor |
|
iv |
Open Inventor |
|
jt |
JT |
|
k3d |
K-3D Native |
|
kmz |
Google Earth Model |
|
lay |
LightScape Layers |
|
lp |
LightScape Presentation |
|
ls |
LightScape |
|
lw |
LightWave 3D |
|
lwo |
LightWave 3D 5.0 Object |
|
lws |
LightWave 3D Scene |
|
lxo |
Luxology Modo |
|
m3g |
JSR-184 |
|
ma |
Maya Scene ASCII |
|
max |
3Ds Max |
|
mb |
Maya Scene binary |
|
map |
Quake 3 |
|
md2 |
Quake 2 Player Model |
|
md3 |
Quake 3 |
|
mdd |
Vertex Key Frame Animation |
|
mel |
Maya Embedded Language Script |
|
mf1 |
I-DEAS |
|
model |
CATIA V4 |
|
mot |
LightWave 3D Motion |
|
mp |
Maya Scene PLE |
|
ms3d |
MilkShape 3D |
|
mtx |
OpenFX Model |
|
ndo |
Nendo |
|
neu |
Pro/Engineer |
|
ntf |
National Transfer Format |
|
obj |
Wavefront |
|
obp |
Bryce |
|
off |
DEC Object file |
|
par, psm, pwd |
Solid Edge |
|
pdb |
PDB Reader v3 |
|
pd, pd |
CADDS |
|
pkg |
I-DEAS, OneSpace Designer |
|
plt |
HP-GL |
|
ply |
Stanford PLY |
|
pov |
POV-Ray Rendering Instructions |
|
pp2 |
Poser |
|
prc, prd |
PRC Adobe 3D Reviewer |
|
prw |
Adobe 3D Reviewer |
|
prj |
3Ds Studio Mesh |
|
prt |
I-DEAS, NX (Unigraphics), Pro/Engineer |
|
pwc |
Pulse |
|
pz3 |
Poser |
|
raw |
Raw Faces |
|
rib |
Renderman |
|
rif |
Radiance |
|
rvt, rte, rfa |
Rent |
|
rwx |
Renderware |
|
s3d |
Strata 3D |
|
sab, sat |
ACIS |
|
scn |
TrueSpace |
|
sda, sdp, sds, sdw, ses |
OneSpace Designer |
|
sdac, sdpc, sdsc, sdwc |
OneSpace Designer |
|
session |
CATIA V4 |
|
sfc |
OpenGIS Simple Features for CORBA format |
|
shp |
3D Studio Shape |
|
shp, shx, dfb, prj |
Shapefile, Esri's open hybrid vector data format |
|
skp |
Google SketchUp |
|
slc, sl, slo |
Renderman |
|
sldasm, sldlfp, sldprt |
SolidWorks |
|
slp |
Pro Engineering |
|
stl |
Stereo Lithography |
|
stp, step |
Standard for the Exchange for Product Data |
|
svg |
Scalable Vector Graphics |
|
tab, dat, id, map |
MapInfo's vector data format |
|
u3d |
Universal 3D |
|
unv |
I-DEAS |
|
vrml |
Virtual Reality Modeling Language |
|
vue |
AutoDesk 3D Studio Animation |
|
vw |
LightScape View |
|
w3d |
Shockwave 3D Scene |
|
wings |
Wings 3D |
|
wire |
Alias Wire |
|
wrl, wrz |
VRML 1.0, VRML 2.0, VRML 97 |
|
x3d, x3dv |
Extensible 3D (VRML 3.0, uses XML, 2004) |
|
x |
Direct X |
|
x b, x t, xmt, xmt txt |
Parasolid |
|
xas, xpr |
Pro/Engineer |
|
xyz |
Simple point cloud formart |
これらのデータ形式の中で、仕様書・解説書とサンプル・データ等を入手したものについて、次の表にまとめる。
|
Extension |
Name |
Originator |
Year of origin |
| OBJ |
Wavefront Object |
Wavefront Technologies, USA |
1985 |
| 3DS (MLI) |
3D Studio Scene |
Autodesk, USA |
1990 |
| 3DM |
Rhinoceros 3D Model |
Rhinoceros, USA |
2000 |
| LWO (LWS, LW, RIG, IFF, FPBM, LW2, LWOS) |
Lightwave 3D Object |
NewTek, USA |
1994 |
| PLY |
Stanford polygon format |
Stanford Graphics Lab, Stanford Univ., USA |
1995 |
| 3D2 (3D, 3D4) |
Stereo CAD-3D Object |
Atari, USA |
1985 |
| C4D |
Cinema 4D |
MAXON Computer GmbH, Germany |
1996 |
| 3DMF |
3D Metafile |
Apple, USA |
1995 |
| DAE |
COLLADA |
Khronos Group Consortium |
2004 |
| VTK (VTHB, VTR, VTI, VTS, VTU, PVTS, PVTU, PVTI) |
Visualization ToolKit |
KitWare Inc., USA |
1993 |
| IGS (IGE, IGES) |
IGES, Initial 2D/3D Graphics Exchange Specifications |
National Bureau of Standards, USA |
1980 |
| SAT (SAB) |
ACIS Model |
Spatial Corp., USA |
1989 |
| STL (STLB) |
StereoLithography |
3D Systems Inc., USA |
1989 |
| OFF (COFF, NOFF, CNOFF, STCNOFF) |
3D Object File Format |
DEC (Digital Equipment Corporation), USA |
1986 |
| COB (SCN, SOB) |
Caligari trueSpace |
Caligari Corp., USA |
1995 |
| SKP (KMZ) |
Google SketchUp |
Google Inc., USA |
2006 |
| FLT |
OpenFlight Scene |
MultiGen Inc., USA |
1994 |
| MGF |
Materials and Geometry Format |
Lawrence Berkeley Laboratory, USA |
1995 |
座標系ついて
デカルト座標系、地心直交座標系
地球の中心を原点、赤道上の経度０をX軸、赤道上の東経90度をY軸、北極をZ軸とする。(平成十四年国土交通省告示第百八十五号)
国家座標系
日本の国土全体を１９のエリアに分割し、それぞれに平面直角座標系を適用したものである。世界座標系
2002年から、国際的な座標系に合わせて修正を加えたもので、 １９のエリア分割は変わらないが、座標値が４００ｍ程度変化した。UTM
インドネシアなどで用いられている、メルカトール座標系である。南極をY座標の原点としている。緯度経度
GPSで得られる位置情報は緯度経度である。近年では建築確認申請を行う際に、敷地の位置を緯度経度で表記する方法が採られている。GoogleEarth等で位置合わせを行うために使用されている。地殻変動の影響
日本付近においては、地殻変動が活発であるために、基準点を始め、地面が流動している。このため、地物の座標値は恒久的に一定ではなく、GPSで計測されるような緯度経度は変化していく。これに対して、基準点（局所座標系の原点）を適宜補正すれば、同じ座標値を用いて、近似的に場所を特定することができる。
東日本大震災に際しては、東北地方の東海岸が約５ｍ、西海岸が約４ｍ東に移動し、差し引き４ｍほど東北地方の東西幅が広がった。このため、所々で活断層が動き、局地的な地震を発生させた。また、大震災後も長い期間にわたり、土地が移動を続けており、岩手県の東海岸では２か月で４０ｃｍ程度東に移動している（余効変動）。 地理院では８月を目途に、基準点の新しい位置を確定する予定であるという。
開発言語・座標系とオープン・ソース資産について
ところが、この問題を複雑にしているのは国家座標系の存在である。 世界各国では、それぞれの地域において実用的な測量業務を実現するために国家座標系を定義している。下げ振りや水準器を用いた測量を行うためには、 その場所の低い重力ポテンシャル面（ジオイド）を水平面とする座標系が定義されているのが便利であった。 我が国の場合には、東京を中心に定められた旧国家座標系においては、この座標系においては、全国が１９の区域に分けられ、それぞれの区域毎の原点が緯度経度で定義されている。
東北日本の東側に重力ポテンシャルの急斜面が存在することから、鉛直線が地球の中心よりも著しくユーラシア大陸側に傾いた直行座標系となっていた。 この傾きを修正するために、２００２年に世界測地系への変更が行われた。これに伴う座標値の変換のために、公的機関から、オープン・ソースのソフトウェアが公開されている。 例えば、国土地理院からは、座標系の変換（旧国家測地系→世界測地系）を行うプログラムが公開されている。
これは、Visual Basic言語で記述されている。プログラムをデバッグ/ステップ実行するためには、ＶｉｓｕａｌＢａｓｉｃの開発環境が必要である。 その開発環境は、Ver.7.0（.NET2002)で大きく改訂されたために、以後のバージョンでは処理することができない。 従って、Ver.6.0を実行する古い環境が必要となる。試してみると、WindowsXPへの6.0開発環境のセットアップは途中でエラーを生じたが、 Windows Server2000へのセットアップは成功した。 この結果に基づいて、Ｃ言語で同様の計算結果を得る関数等の作成を行った(2011年７月）。
時間ついて
西暦と和暦
古代ローマでは、１年は10月であった。ユリウス・カエサルによりユリウス暦が導入され、１年を365日とし、４年に１度閏年を設ける方法が、紀元前45年から実施された。JanusとFebruariが追加され１年は12か月となった。ユリウス暦では３月を年次の始まりとするが、会計年度をその２カ月前の１月からとした。これはグレゴリオ暦に継承され１月から新年。
神学者ディオニュシウス・エクシグウスの計算により西暦年が定められる532年より前は、ディオクレティアヌスの即位(284)を紀元とする年号が用いられていた。
西暦年は１年から始まる。その前の年は紀元前１年。キリスト生誕年の推定に基づき西暦532年から適用された。1年から531年までは概念上の存在であり、実際の紀年法として使用されたことはない。
1582年にユリウス暦からグレゴリオ暦(太陽暦)に変更され、現在に至っている。変更内容は、100年に１回閏月を省略するが、400年に１回は閏月とする点。
カトリック系では1582年10月4日の翌日が10月15日になり、1582年10月5日から10月14日までは存在しない。
導入が遅れたプロテスタント系では1752年9月2日の翌日が9月14日になり、1752年9月3日から9月13日までは存在しない。
日本では、明治５年(1872)に西暦が導入され、明治５年１２月２日の翌日が明治６年１月１日となった。
和暦は大化(645)に始まった太陰・太陽暦の一種。
元号は、年の中途で変更（改元）が行われた。南北朝時代には二つの元号が併存する。
明治５年以前の元号・和暦の年をグレゴリオ暦の年に変換する場合には、月日まで考慮する必要がある。
GMTとローカル時刻
グリニッジ標準時。これに対して、世界各地でローカル時刻が設定されている。UNIX系とWINDOWS系
UNIX時間はgettimeofday(long*);で取得。1970年1月1日 UTCの真夜中から1μs単位で,符号付き整数値
Microsoft Windows NTではGetSystemTime(long*);で取得。
1601年1月1日0時0分（UTC）（先発グレゴリオ暦）からの1ms単位での経過時間(整数)
時間に関するライブラリ関数やサブルーチンは、一般的に時刻表現相互間の変換だけでなく、等時帯（地球上の時差）、夏時間、閏秒またユーザーのロケール設定に合わせて調節する機能がある。VS2005では、Ｃ言語のtime関数は何も規定していない。
いわゆる、仮想化技術について
例えば現在、Windows上で、かつてのN88BASICで書かれたプログラムを実行するためには、①T98-NEXT というハードウェアのエミュレータを実行し、この上でＯＳとプログラムを実行する方法、②N88互換BASIC for Windows95というN88BASICインタプリタ実行環境のエミュレータを使用する方法などがある。しかし、これのプラットフォームとなっているWindowsマシンが過去のものとなった場合には、エミュレーションもそのままでは実行できなくなる。
これを一般化し、様々な時代のハード、ＯＳを仮想化した博物館マシンがあれば、任意のハード、ＯＳが再現でき、たとえば1982年のOASIS(専用ワープロ）で作成した文書ファイルを修正して印刷することもできるであろう。更に、このような博物館マシンを仕様としてＰＦ定義し、それを不変化することができれば、それを前提として各時代のハード、ＯＳの定義ファイルに不変性を付与できる。
ソフトプロセッサ
いわゆるプログラマブルロジックデバイス(PLD)が発達した結果、これらの上にハードロジックをプログラムすることにより、マイクロプロセッサを実装することができるようになった。
例えば、1chipMSXプロジェクト(www.msx.d4e.co.jp)では、生産終了となったパソコンのシステム全体をFPGAチップの上に再現したものである。(*Field Programmable Gate Arrayの略）
二村の射影と景観シミュレータの外部関数について
これによると、定数C、ランタイム・データRを引数とするプログラム
π(C,R)
は、コンパイラαにより、
α(π,C）
という実行形式に変換でき、α（π, C) (R)は、引数がランタイム・データのみとなるため、計算過程が簡略化することが期待できる（例えば、Y="1"+C+R というプログラムは、定数Cが２であれば、Y=3+Rの形に変換できる）。
インタープリタ int 上で動くソースコードをS,ランタイムデータをRとすると、Sは定数、Rはランタイムと見て、
int(S,R)
は、同様にして、α（int,S) (R) という、Rのみを引数とする実行形式に変換することができる（第一射影）。
更に、α(int, S)は、α(α,int)(S)の形に変換でき、α(α,int)は、ソースコードを実行形式に変換するコンパイラである（第二射影）。
更に、α（α, int)は、α(α､α)(int)の形に変換でき、このα（α,α）は、インタプリタをコンパイラに変換するコンパイラ・コンパイラである（第三射影）。
景観シミュレータにおける外部関数は、これと同じような動作をしている。
Ｇ＝ＦＩＬＥ（Ｃ）；は、固定的な形状ファイルを参照するのみであるのに対して、
Ｇ＝ＦＩＬＥ（Ｃ, Ｒ）；は、実行形式C.exe を起動し、ランタイム値Rをこれに渡す。
この時、Ｃ.exe は、引数Ｒをパラメータとして補完し、完全（固定的）な形状データを返す。従って、上記のα（π，Ｃ）に相当する機能である。
このランタイム値には、原始図形のパラメータ（例えば「球」の半径）のような単純な少数の数値から、複雑な形状を記述したファイルまで含まれる。
そこで、実用的には、多くのファイルコンバータがこの形式で実装されている。
Ｇ＝ＦＩＬＥ（コンバータ名，変換元ファイル名）；
（例）G=FILE(FIRE2LSS, gaiku.dat);
この時、コンバータ（例えばFIRE2LSS.exe)は、特定のOS（現在はWindows）の上でしか使用できない実行形式である。
もし、インタープリタ interpret.exe を外部関数として実装し（まだない）、この上で動作するスクリプトによりコンバータが記述できれば、同じ変換を、
Ｇ＝ＦＩＬＥ（INTERPRET, SCRIPT, 変換元ファイル名）；
により得ることができる（第一射影）。これにより、テキストファイルであるSCRIPTは、異なるOSの上でも共通に使用することができる。
COMPILE.exe が、インタプリタと同じ言語のスクリプトを引数として実行形式を生成し、これにランタイム引数を渡して実行させる機能を有するとすれば、同じ変換を、
Ｇ＝ＦＩＬＥ（COMPILE, SCRIPT, 変換元ファイル名）；
により同じ結果を得ることができる（第二射影）。
下記の仮想コンバータの実装においては、この段階まで実現しており、WindowsとAndroid上で、共通のSCRIPTを使用することができるようになった。
更に、コンパイラ・コンパイラＣＣ(cc.exe)が、スクリプトのための文法規則GRAMMARからコンパイラを生成してそれを実行するとすれば、
Ｇ＝ＦＩＬＥ（CC, GRAMMAR, SCRIPT, 変換元ファイル名）；
により同じ結果を得ることができる(第三射影)。
このGRAMMARを永久不変の約束事として定義しておき、その上で変換元ファイルにSCRIPTを添付したものを保存しておけば、ハード、ＯＳ、アプリの栄枯盛衰を超えて、データの可読性を維持することができる。
現在の仮想コンバータのソースコードはC言語で記述しており、共通のソースコード(GRAMMAR)をVS2005とAndroid-ndkのどちらでもコンパイルし実行することができる。
仮想コンバータの試作
概要
保存する三次元データファイルの構造を記述したメタファイルを読み込んで、この規定に基づいてデータファイルを解読し、必要な形式で出力する仕組みを、少なくとも一つ実現することを第２年度の目標とした。このような仕組みを実現するために、様々な方法がありうる。しかしながら、最適な一つの方法に収斂させることは必ずしも重要ではない。一つの方法が実現されており、その方法に基づくメタファイルが原本に添付されていれば目的を達することができる。
将来的に、別の方法が実現された場合、その方法による別の形式のメタファイルが作成可能となるが、それは今回試作する形式を置き換えるものではなく、これに付け加えることによって、可読性をより高めることとなるだろう。
メタファイルの記述スタイル、処理系の実装方法をいくつか検討した結果、C言語を簡略化した制御構造と、LSS-G形式のコマンドが組み込み関数として利用できる処理系が最速で実現できると判断した。
C言語によるファイル・コンバータは、既に景観シミュレーション・システムのための外部関数の形式で蓄積がある。また、LSS-G形式は、セミコロンをセパレータとするC言語ライクなコマンド記述形式を有していることから、馴染みが良い。
実装に当たっては、具体的な出力形式が無ければ結果を確認できないことから、以下の４段階を設定し、開発工程を進めた。
(1) VC-1F：データ・ファイルを読み込み、別の形式のデータ・ファイルを出力するコンバータとしての実装(2011年8月10月)
(2) VC-2V：仮想現実装置に三次元データを出力・表示する実装(2011年10月～12月)
(3) VC-3M：携帯端末に三次元モデルを表示し、背景実写とAR合成表示する実装（2011年12～2012年2月)
(4> VC-4D：データベースに入力する実装
ファイル・コンバータ(VC-1F)
オープンソースのＣ言語コンパイラに対して、頂点、線、面、シーングラフ構造、テクスチャその他を定義するための組み込み関数を追加実装することにより実現した。特長として、数値の標準形式として整数・浮動小数のみならずクォータニオンを使用できるようにした。これを用いて、地球座標系、緯度経度、国家座標系等の変換関数も簡潔に記述できるようにした。
この処理系は、ビットストリームを入力し、ビットストリームを出力するだけなので、ＧＵＩに関するコーディングを必要としなかった。コマンドラインで起動し変換を行う（Windows系では、コンソール・アプリケーション）。
起動に際しては、引数として入力メタファイル、入力データ・ファイル、出力データ・ファイルの３引数を指定する。
起動後は、まずコンパイラとして動作し、入力メタファイルをコンパイルして実行形式を生成する。
次に、実行形式がインタープリタとして動作し、入力データ・ファイルを読み込み、解釈して結果をファイル出力する。
エラーが発生した場合には、結果ファイルにメッセージを出力する方法とした。 メタファイルの最も単純な形式として、LSS-G形式のメタファイルを入力すると、変換対象のデータファイルにかかわりなく、メタファイルの各コマンドをそのまま実行し、その結果を出力する。
これにより、変換処理のデバッグを進めることができた。 例えば、メタファイルに記述されたP=COORD(1,2,3);というコマンドが検出されると、COORD組み込み関数が実行され、処理系は、座標値(1,2,3)という頂点オブジェクトを一つ登録しそのIDとしてｎを得、これを変数Pに代入する。
次にV=VERTEX(P);というコマンドが実行されると、変数Pに代入されていたIDを引数として、VERTEX組み込み関数が実行され、その結果が変数Vに代入される。
また、例えば高さH、半径Rの水平の円周上の６の等分点を定義するためには、
int i,P[6];
for(i=0;i<6;i++){
P[i] = COORD(R*cosd(i*60),R*sind(i*60),H);
}
とすればよい。ここで、cosd, sindはそれぞれ、度を単位とする引数とする三角関数である。このように組み込み関数となったCOORDコマンドの引数として定数だけでなく変数や関数を使用できる点が、従来のLSS-Gコマンドとは異なっている。
入力に関しては、FILE構造体やfopen等の関数をユーザーに見せるのではなく、変換対象とするデータを有限長の配列として扱うような方法とした。最小限の関数から出発し、適宜拡張している。例えば、GETC()関数は、配列から１バイト取り出すと共に、ポインタを一つ進める。GETINT（int n)関数は、現在のアドレスからnバイト分を整数値として解釈してその値を返す。
仮想現実(VC-2V)
この実装方法においては、処理系はメタファイルとデータファイルを処理した結果を、３Dディスプレイに表示する。メタファイルを記述する文法や組み込み関数はVC-1Fと同様であるが、出力部分が異なっている。そこで、仮想コンバータの出力部分を差し替えるために、出力関数ライブラリを作成し、そのライブラリを差し替えることにより対応した。
具体的には、仮想コンバータのビルド一式において、VC-１FとVC-2Vで異なるのは、リンクする出力ライブラリの部分である。VC-1Cにおける出力ライブラリの能動的な機能は、ファイル出力であった。これに対して、この版における出力ライブラリの能動的な機能は、メモリ空間上に三次元オブジェクトを構築し、処理終了後に仮想現実表示処理系に制御を渡すことである。
そして、この出力インターフェースを構成する関数（仮想コンバータのコンパイルに使用する）は、メタファイルのための組み込み関数（メタファイルのコンパイルに使用する）と同じ構成とした。
実装においては、WindowsをOSとするPCで、OpenGLを用いたステレオ描画を行うシステムを作成した。これを国土交通省版景観シミュレータの外付けプラグインDLLの形で実現することにより、開発途上のデータの確認の手間を大幅に軽減することができた。
上記の出力ライブラリの分離に伴い、先に開発したファイルコンバータ（VC-1F)も、ファイル出力部分をライブラリとして独立させ、それ以外の仮想コンバータのソースコードは共通とした。
背景との画像合成(VC-3M)
この実装方法においては、携帯端末の上で、背景画像として内蔵CCDカメラから取り込んだ画像の上に、解析・入力した三次元モデルを合成表示(AR表示）する。入力部分と出力部分の構成は、VC-2Vとほぼ同様であるが、プラットフォームとするOSがAndroidであり、CPU及びコンパイラが異なっている。描画機能においても、OpenGL
ESを用いたことから命令セットが縮小されている。
携帯端末には、背景画像を取得するカメラの他に、位置情報を取得するGPSセンサーと、姿勢情報を取得するために地磁気センサー、加速度センサーが備わっていることから、端末を移動・回転させるに従い変化する位置・姿勢を表示に反映させることができる。
このことにより、現在は廃墟・空地となっている場所に、かつて建っていた建築物をデータから再現表示することや、まだ計画段階にある将来の建物を、携帯端末を透かして予測表示することが可能である。
端末に対するGUI（ユーザーの操作画面）の処理、及び各種センサーの処理を、現在支配的に使われているECLIPSE開発環境上でjava言語により開発した。一方、仮想コンバータの部分の移植には、C言語のソースコードをネーティブのARMプロセッサの機械語にコンパイル・ビルドする、NDK開発環境を用いた。また、OpenGL描画部分に関しても、VC-2Vのソースコード（C言語）を多く活用するために、NDK開発環境を用いた。
開発結果を国産のタブレットに搭載し、東京、つくば及び釜石でテストを行い、位置精度等を計測した。
（携帯端末版仮想コンバータVC-3Mのセットアップ方法及び操作方法等については→こちら
データベース入出力(VC-4D)
この実装方法においては、ネットワークから投稿されたデータ＋メタファイルのセットを解析して、データベース上にデータ構造を展開する。 即ち、この版において、仮想コンバータとリンクする出力ライブラリの部分は、・ライブラリにおける出力ライブラリ上記COORD関数は、COORDテーブルに一つの頂点座標を登録するSQLコマンドを生成し実行する。 また逆にリクエストに添付されたメタファイルに従って、データを別形式に再コーディングして送付するような使用方法を実現した。 従って、仮想コンバータの各コマンドを実装するは、データベース（例えばSQLサーバー）への入力部分となる。 また、仮想コンバータのファイル出力動作を定義するコマンドとして、SQLデータベースから頂点座標、線、面、立体といったオブジェクトを順次取得するコマンドを追加した。 これに基づいて、2013年２月段階で、以下のようなフォームを用いた入出力機能が初めて稼働した。 極めて広範な動作が可能な処理系であるため、様々なデータ形式、サンプルデータによるテスト・デバッグが求められる。 現在、研究所のLAN環境で動作しており、奥尻島復興等の特定目的に限定して、サンプルデータのダウンロードのためのWEB公開に向けて作業中である(131126時点)。
現在のVer.1.0のバックグランドで動作しているデータベースのテーブル構成を、SQLコマンドで表現したものを、資料１に示す。また、現段階での仮想コンバータのメタファイルの文法概要(Ver.1.0)を、資料２に示す。
これらは、まだ完成形ではないが、コマンド大幅な拡張は予想しておらず、むしろ不要なコマンドを削減したり、動作の定義を明確化したいと考えている。
初期画面
アップロード画面
ダウンロード画面
NILIM
