開発製作記事

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

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

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

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

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

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

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

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

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ソリッドのデータ構造は、基本的には、サーフェス・モデルにおける面を、パラメトリックな面(仮に「緬」と呼ぶ)に拡張したものと理解することができる。立体は、ポインタで繋がれた、緬により包含される。緬は緬の属性(平面か、円錐面か、球面か、トーラス面か、スプライン面か、それぞれについてのパラメータ)と、縁を構成する辺(ポインタで繋がれてループを形成する)により構成される。
・縁は、複数のループから成る。例えば、円柱形の場合には、側の緬(円錐)は、上と下に二つのループを持つ。
・一つのループは、複数の辺から構成される。
・スプライン緬とスプライン緬の交線などは、更にスプライン曲線として記述されることになる。
・スプライン曲線は、グラフィックス表示において、視点からの距離に応じた精度でポリゴンに分割するような処理には適しているが、このようなスプライン近似においては、交線の形状は厳密な定義にはなっていない。従って、幾何学演算を行うためには、あくまでも近似的な性格を帯びる。

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

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

様々な三次元データのファイル形式

三次元データ形式は、増加の一途を辿り、2010年時点では、300種類を超えている。主なデファクト・スタンダードについて、次の表にまとめる。

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

座標系ついて

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

開発言語・座標系とオープン・ソース資産について

  GISデータや三次元データを扱う上では、座標系は重要な要素の一つである。一般に、持ち運びできるようなオブジェクトの場合には、 物体の近傍に座標原点が置かれている。 これに対して、住宅や社会資本などの地面に定着したオブジェクトの場合には、座標系が異なる場合に、位置や方位を知ることが難しくなる。 GPSの時代には、地球を記述する座標系とオブジェクト近傍の座標系は平面直行座標系の間の変換マトリクスの問題に帰着する。
 ところが、この問題を複雑にしているのは国家座標系の存在である。 世界各国では、それぞれの地域において実用的な測量業務を実現するために国家座標系を定義している。下げ振りや水準器を用いた測量を行うためには、 その場所の低い重力ポテンシャル面(ジオイド)を水平面とする座標系が定義されているのが便利であった。 我が国の場合には、東京を中心に定められた旧国家座標系においては、この座標系においては、全国が19の区域に分けられ、それぞれの区域毎の原点が緯度経度で定義されている。
 東北日本の東側に重力ポテンシャルの急斜面が存在することから、鉛直線が地球の中心よりも著しくユーラシア大陸側に傾いた直行座標系となっていた。 この傾きを修正するために、2002年に世界測地系への変更が行われた。これに伴う座標値の変換のために、公的機関から、オープン・ソースのソフトウェアが公開されている。 例えば、国土地理院からは、座標系の変換(旧国家測地系→世界測地系)を行うプログラムが公開されている。
 これは、Visual Basic言語で記述されている。プログラムをデバッグ/ステップ実行するためには、VisualBasicの開発環境が必要である。 その開発環境は、Ver.7.0(.NET2002)で大きく改訂されたために、以後のバージョンでは処理することができない。 従って、Ver.6.0を実行する古い環境が必要となる。試してみると、WindowsXPへの6.0開発環境のセットアップは途中でエラーを生じたが、 Windows Server2000へのセットアップは成功した。 この結果に基づいて、C言語で同様の計算結果を得る関数等の作成を行った(2011年7月)。

時間ついて

西暦と和暦
古代ローマでは、1年は10月であった。ユリウス・カエサルによりユリウス暦が導入され、1年を365日とし、4年に1度閏年を設ける方法が、紀元前45年から実施された。JanusとFebruariが追加され1年は12か月となった。
ユリウス暦では3月を年次の始まりとするが、会計年度をその2カ月前の1月からとした。これはグレゴリオ暦に継承され1月から新年。
神学者ディオニュシウス・エクシグウスの計算により西暦年が定められる532年より前は、ディオクレティアヌスの即位(284)を紀元とする年号が用いられていた。
 西暦年は1年から始まる。その前の年は紀元前1年。キリスト生誕年の推定に基づき西暦532年から適用された。1年から531年までは概念上の存在であり、実際の紀年法として使用されたことはない。
1582年にユリウス暦からグレゴリオ暦(太陽暦)に変更され、現在に至っている。変更内容は、100年に1回閏月を省略するが、400年に1回は閏月とする点。
カトリック系では1582年10月4日の翌日が10月15日になり、1582年10月5日から10月14日までは存在しない。
導入が遅れたプロテスタント系では1752年9月2日の翌日が9月14日になり、1752年9月3日から9月13日までは存在しない。
日本では、明治5年(1872)に西暦が導入され、明治5年12月2日の翌日が明治6年1月1日となった。
和暦は大化(645)に始まった太陰・太陽暦の一種。
元号は、年の中途で変更(改元)が行われた。南北朝時代には二つの元号が併存する。
明治5年以前の元号・和暦の年をグレゴリオ暦の年に変換する場合には、月日まで考慮する必要がある。
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では、C言語のtime関数は何も規定していない。

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

 あるコンピュータ上で、異なるハード、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の略)

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

 二村良彦(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, gaiku.dat);
この時、コンバータ(例えばFIRE2LSS.exe)は、特定のOS(現在はWindows)の上でしか使用できない実行形式である。
もし、インタープリタ interpret.exe を外部関数として実装し(まだない)、この上で動作するスクリプトによりコンバータが記述できれば、同じ変換を、
 G=FILE(INTERPRET, SCRIPT, 変換元ファイル名);
 により得ることができる(第一射影)。これにより、テキストファイルであるSCRIPTは、異なるOSの上でも共通に使用することができる。
 COMPILE.exe が、インタプリタと同じ言語のスクリプトを引数として実行形式を生成し、これにランタイム引数を渡して実行させる機能を有するとすれば、同じ変換を、
 G=FILE(COMPILE, SCRIPT, 変換元ファイル名);
 により同じ結果を得ることができる(第二射影)。
 下記の仮想コンバータの実装においては、この段階まで実現しており、WindowsとAndroid上で、共通のSCRIPTを使用することができるようになった。
 更に、コンパイラ・コンパイラCC(cc.exe)が、スクリプトのための文法規則GRAMMARからコンパイラを生成してそれを実行するとすれば、
 G=FILE(CC, GRAMMAR, SCRIPT, 変換元ファイル名);
により同じ結果を得ることができる(第三射影)。
 このGRAMMARを永久不変の約束事として定義しておき、その上で変換元ファイルにSCRIPTを添付したものを保存しておけば、ハード、OS、アプリの栄枯盛衰を超えて、データの可読性を維持することができる。
 現在の仮想コンバータのソースコードはC言語で記述しており、共通のソースコード(GRAMMAR)をVS2005とAndroid-ndkのどちらでもコンパイルし実行することができる。  

仮想コンバータの試作

概要
 保存する三次元データファイルの構造を記述したメタファイルを読み込んで、この規定に基づいてデータファイルを解読し、必要な形式で出力する仕組みを、少なくとも一つ実現することを第2年度の目標とした。
 このような仕組みを実現するために、様々な方法がありうる。しかしながら、最適な一つの方法に収斂させることは必ずしも重要ではない。一つの方法が実現されており、その方法に基づくメタファイルが原本に添付されていれば目的を達することができる。
 将来的に、別の方法が実現された場合、その方法による別の形式のメタファイルが作成可能となるが、それは今回試作する形式を置き換えるものではなく、これに付け加えることによって、可読性をより高めることとなるだろう。
 メタファイルの記述スタイル、処理系の実装方法をいくつか検討した結果、C言語を簡略化した制御構造と、LSS-G形式のコマンドが組み込み関数として利用できる処理系が最速で実現できると判断した。
 C言語によるファイル・コンバータは、既に景観シミュレーション・システムのための外部関数の形式で蓄積がある。また、LSS-G形式は、セミコロンをセパレータとするC言語ライクなコマンド記述形式を有していることから、馴染みが良い。
 実装に当たっては、具体的な出力形式が無ければ結果を確認できないことから、以下の4段階を設定し、開発工程を進めた。
 (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)
 オープンソースのC言語コンパイラに対して、頂点、線、面、シーングラフ構造、テクスチャその他を定義するための組み込み関数を追加実装することにより実現した。
 特長として、数値の標準形式として整数・浮動小数のみならずクォータニオンを使用できるようにした。これを用いて、地球座標系、緯度経度、国家座標系等の変換関数も簡潔に記述できるようにした。
 この処理系は、ビットストリームを入力し、ビットストリームを出力するだけなので、GUIに関するコーディングを必要としなかった。コマンドラインで起動し変換を行う(Windows系では、コンソール・アプリケーション)。
 起動に際しては、引数として入力メタファイル、入力データ・ファイル、出力データ・ファイルの3引数を指定する。
 起動後は、まずコンパイラとして動作し、入力メタファイルをコンパイルして実行形式を生成する。
 次に、実行形式がインタープリタとして動作し、入力データ・ファイルを読み込み、解釈して結果をファイル出力する。
 エラーが発生した場合には、結果ファイルにメッセージを出力する方法とした。  メタファイルの最も単純な形式として、LSS-G形式のメタファイルを入力すると、変換対象のデータファイルにかかわりなく、メタファイルの各コマンドをそのまま実行し、その結果を出力する。
 これにより、変換処理のデバッグを進めることができた。   例えば、メタファイルに記述されたP=COORD(1,2,3);というコマンドが検出されると、COORD組み込み関数が実行され、処理系は、座標値(1,2,3)という頂点オブジェクトを一つ登録しそのIDとしてnを得、これを変数Pに代入する。
  次にV=VERTEX(P);というコマンドが実行されると、変数Pに代入されていたIDを引数として、VERTEX組み込み関数が実行され、その結果が変数Vに代入される。
  また、例えば高さH、半径Rの水平の円周上の6の等分点を定義するためには、
  
  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()関数は、配列から1バイト取り出すと共に、ポインタを一つ進める。GETINT(int n)関数は、現在のアドレスからnバイト分を整数値として解釈してその値を返す。
仮想現実(VC-2V)

 この実装方法においては、処理系はメタファイルとデータファイルを処理した結果を、3Dディスプレイに表示する。メタファイルを記述する文法や組み込み関数はVC-1Fと同様であるが、出力部分が異なっている。そこで、仮想コンバータの出力部分を差し替えるために、出力関数ライブラリを作成し、そのライブラリを差し替えることにより対応した。
  具体的には、仮想コンバータのビルド一式において、VC-1Fと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開発環境を用いた。
 開発結果を国産のタブレットに搭載し、東京、つくば及び釜石でテストを行い、位置精度等を計測した。

引き続き、センサーによる計測誤差の補正方法(キャリブレーション)機能の改善を行い、  2013年11月16日の施設公開に際して、国総研本館の裏庭に、奥尻島の古写真から復原した1993年被災前の集落データを配置したものをサンプルとして、表示デモを行った。
   (携帯端末版仮想コンバータVC-3Mのセットアップ方法及び操作方法等については→こちら  
データベース入出力(VC-4D)

 この実装方法においては、ネットワークから投稿されたデータ+メタファイルのセットを解析して、データベース上にデータ構造を展開する。  即ち、この版において、仮想コンバータとリンクする出力ライブラリの部分は、・ライブラリにおける出力ライブラリ上記COORD関数は、COORDテーブルに一つの頂点座標を登録するSQLコマンドを生成し実行する。  また逆にリクエストに添付されたメタファイルに従って、データを別形式に再コーディングして送付するような使用方法を実現した。 従って、仮想コンバータの各コマンドを実装するは、データベース(例えばSQLサーバー)への入力部分となる。 また、仮想コンバータのファイル出力動作を定義するコマンドとして、SQLデータベースから頂点座標、線、面、立体といったオブジェクトを順次取得するコマンドを追加した。 これに基づいて、2013年2月段階で、以下のようなフォームを用いた入出力機能が初めて稼働した。 極めて広範な動作が可能な処理系であるため、様々なデータ形式、サンプルデータによるテスト・デバッグが求められる。 現在、研究所のLAN環境で動作しており、奥尻島復興等の特定目的に限定して、サンプルデータのダウンロードのためのWEB公開に向けて作業中である(131126時点)。

現在のVer.1.0のバックグランドで動作しているデータベースのテーブル構成を、SQLコマンドで表現したものを、資料1に示す。
また、現段階での仮想コンバータのメタファイルの文法概要(Ver.1.0)を、資料2に示す。
これらは、まだ完成形ではないが、コマンド大幅な拡張は予想しておらず、むしろ不要なコマンドを削減したり、動作の定義を明確化したいと考えている。
初期画面
初期画面
アップロード画面
アップロード画面
ダウンロード画面
ダウンロード画面
Last updated : 2013/11/27 21:9:49
NILIM