建築確認APIのプロトタイプの作成と考察

Jun 30, 2022 · 読み終えるまでの時間：1分 · ifcopenshell ifc.js  ·
share:

背景

  • 以前、「IFCの属性情報を用いた建築確認自動化の可能性に関する研究」という題で論文を執筆した。
  • IFC viewerの機能を中心としたフレームワークであるifc.jsを知り、建築確認機能を持つIFC viewerを作成できると考えた。

Webサービス

初期構成

まず最初に考えた構成図は次図

ifc bc first architecture

viewerにifc.jsを採用し、建築確認機能をAPI化させる。APIはAWS Lambdaを採用することを想定。（今後変更する可能性あり）

しかし、ここで課題となるのはviewerとAPIの間でIFCのデータをどのような形式で送受信させるかということである。

そこでIFCをJSON形式に変換する方法などを視野に入れ、検討を行った。

IFCデータのやり取りの方法の検討

前述した通り、IFCデータをviewerとAPIの間においてどのような形式でやりとりを行うのかという課題がある。今回はifc-spfデータ（以下、ifcspf）またはIFCをjsonに変換したデータ（以下、ifcjson）を対象とした。なお、jsonに変換する際は以前記事にしたifcJSONを用いて行った。

  1. ifcspfを用いる方法：ifcspfを用いる場合はifcopenshellを用いてifcデータを読み込み解析を行う
    1. 利点
      1. ifcのデータ構造をあまり意識せずに処理できる
    2. 欠点
      1. 処理の環境がifcopenshellに依存する
  2. ifcjsonを用いる方法
    1. 利点
      1. 処理の環境がifcopenshellなどifcのデータに依存せずに処理できる
      2. 処理内においてifcをデータベースとして扱うことができる
    2. 欠点
      1. データ構造を一つ一つ確認してプログラムの設計やAPIの設計を行わなければならない

それぞれについては以上のような利点と欠点が考えられた。

また、データのサイズについても考慮した。それぞれのデータのサイズとしては次表の通りとなっている。

種類 サイズ（MB）
ifcspf 約7.8MB
ifcjson 約65MB

以上より、ifcspfとifcjsonでは主にサイズの観点からifcspfを使用した方が良いと判断した。

プロトタイプの作成

概要

プロトタイプに関しては、ifc.jsはまだチュートリアルを終えた程度であったので代替としてjupyter notebookを使用した。プロトタイプの構成図としては次図である。

ifc bc prototype architecture

処理概要としては、まずifcspfをtextと読み込み圧縮バイナリ化した後、APIに送信を行う。この時、ifcデータの特定の部材のみなどではなく全てのデータを送信する。解析API側では受信したデータを解凍し解析を行い結果を返す。

IFCデータの圧縮

前項の内容から、ifcデータに関してはifcspfを用いて行う。しかし、データサイズはまだ大きいため圧縮が必要である。処理についてはpythonを使用して作成したため、標準パッケージを比較した結果lzmaを用いて行った。圧縮後のデータとしては約1.2MBまで落とすことができた。

APIインターフェース

input(body)

1{
2	'ifc': xxxx, // ifcのデータを圧縮しバイナリ化したもの
3	'metadata': { 
4		// レスポンスにも保持される内容
5		'target': 'test.ifc',
6	}
7}

output(body)

success

 1{
 2	'message': 'Success', // メッセージ
 3	'result': {
 4		'conformityElements': [ // 適合部材
 5			{
 6				'globalId': 'yyyy',
 7				'type': 'IfcWall',
 8				'name': '標準壁',
 9				'propertySetNum': 5, // このオブジェクトに含まれるプロパティセットの数
10				'propertySet': [
11					{
12						'name': 'FireRating',
13						'value': 60,
14					}, ...
15				],
16			}, ...
17		],
18		'notConformityElements': [ // 不適合部材
19		...
20		],
21		'exceptionElements': [ // 例外部材
22		...
23		]
24	},
25	'metadata': { 
26		'target': 'test.ifc',
27	}
28}

failed

1{
2	'message': 'Failed', // メッセージ
3	'error': 'ValidationError', // エラーメッセージ
4	'metadata': { 
5		'target': 'test.ifc',
6	}
7}

考察

プロトタイプではIFCデータのサイズが大きいため、データを圧縮し解析処理に送信した。しかしこの方法は、解析処理に不必要であるIFCデータも送信してしまっているためデータサイズが大きくなっていると考えられる。つまり、機能ごとに必要最低限のデータを取り出すことが可能な仕組みを作ることによってこの課題は解決できると考えられる。
さらに現状のファイルベースのデータ管理では、データの作成や更新に適している形とは言えないため、IFCを基にしたデータベースを介した構成にする必要があるだろう。（下図）

ifc bc second