都市デジタルツイン — パート2: CityGMLの構造と体系的なデータ検証方法

パート1では、中核的な原則を合意しました。それは、CityGMLがプロジェクト全体のセマンティックなSingle Source of Truth (SSOT)であるということです。3D Tiles、OBJ、FBXのようなフォーマットは表示目的の出力フォーマットに過ぎません。ビジュアルに特化しながらセマンティクスに乏しい3Dモデルを追い求めようとすると、分析とシミュレーションの段階に入った途端にプロジェクトは失敗するでしょう。

しかし、オリジナル標準で保存するという考え方から、実際のファイルを処理するまでの道のりは非常に困難な課題です。ベンダーから数十GBもの重いCityGMLソースデータを受け取った際、それをデータパイプライン（FMEなど）や3Dエンジン（Cesium、Unrealなど）に直接投入することは禁物です。内部構造が不明な巨大なXMLファイルを盲目的に解析すると、直接Out of Memory (OOM)エラーやシステムクラッシュを引き起こします。

パート1の最後で提示された「自分のデータセットが、特定の課題に利用するために正しいオブジェクト、属性、構造を含んでいることをどうやって知るのか？」という質問に答えるためには、本番環境のパイプラインに投入する前に、以下の体系的な手順に従ってデータを検査し、検証する必要があります。

1. OGCオープンスタンダードとCityGMLの真の性質

OGC (Open Geospatial Consortium)は、地理空間データのためのオープンスタンダードを確立する国際機関です。このエコシステムにおいて、CityGMLは3D都市モデルの保存と交換に用いられる中核的な標準（GML3アプリケーションスキーマ）です。

CityGMLをFBXやOBJのような純粋なグラフィックフォーマットと混同しないでください。CityGMLはXMLテキストベースのデータベースです。CityGMLの最大の利点は、LOD（Level of Detail）構造を通じて、ジオメトリ、トポロジ、セマンティクス間の整合性と密接な関連性を維持することにあります。

2. “CityGML内部構造の「解剖」

CityGMLの構造は、XML名前空間を通じて非常に厳密にモジュール化されています。すべてを詰め込むのではなく、データはcore（コア）、bldg（建物）、tran（交通）、veg（植生）などの独立した空間に分割されます。

以下は、CityGMLファイルの基本的なスキーマです。

XML

<?xml version='1.0' encoding='UTF-8'?><core:CityModel xmlns:core='http://www.opengis.net/citygml/2.0'    xmlns:bldg='http://www.opengis.net/citygml/building/2.0'    xmlns:gml='http://www.opengis.net/gml'>    <!-- 1. バウンディングボックスとCRS: 境界座標と座標参照系 -->    <gml:boundedBy>        <gml:Envelope srsName='urn:ogc:def:crs,crs:EPSG::25832'>            <gml:lowerCorner>458868.0 5438343.0 112.0</gml:lowerCorner>            <gml:upperCorner>458892.0 5438362.0 117.0</gml:upperCorner>        </gml:Envelope>    </gml:boundedBy>    <!-- 2. フィーチャノード: 実際のオブジェクトを含む -->    <core:cityObjectMember>        <bldg:Building gml:id='UUID_7b1a5a6f-ddad'>            <!-- メタデータ (セマンティック) -->            <gml:name>Building A</gml:name>            <bldg:yearOfConstruction>1985</bldg:yearOfConstruction>            <!-- ジオメトリ & LOD -->            <bldg:lod2Solid>               <gml:Solid>                   <gml:exterior>...</gml:exterior>               </gml:Solid>            </bldg:lod2Solid>        </bldg:Building>    </core:cityObjectMember></core:CityModel>

上記のコードを読む際、エンジニアは主に以下の3つのノードの解析にのみ注意を払う必要があります。

1. <gml:Envelope>: 空間バウンディングボックス（Bounding Box）と座標参照系（CRS）を定義します。
2. <core:cityObjectMember>: オブジェクトのタイプを識別します。
3. <bldg:lodXSolid>: LODレベルに対応する幾何学的構造を定義します。

3. 実用的なチェックリスト：システムデータの検証5ステップ

ベンダーから提供されたCityGMLファイルが、課題のオブジェクト、属性、構造を正しく満たしているかどうかをどうやって知るのでしょうか？データをシステムにインポートする前に、以下の5つの検証ステップを順に実行してください。

ステップ1: XMLスキーマ (XSD) の検証

• アクション: 目視では行いません。Pythonスクリプト（lxmlライブラリとiterparseメカニズムを使用してRAMの消費を避ける）または専用ツールを実行し、OGCの標準XSDセット（例: core.xsd、building.xsd）とファイル全体を照合します。
• 理由: ベンダーは、誤った標準のカスタムタグを定義したり、名前空間の宣言を怠ったりすることがよくあります。このステップをスキップすると、ターゲットマップエンジンのパーサーは致命的なエラーに遭遇し、システムが即座にクラッシュします。

ステップ2: 座標参照系 (Coordinate Reference System – CRS/EPSG) の検査

• アクション: <gml:Envelope>ノード内のsrsName値を読み取ります。GMLは、この元のCRSが内部のすべてのジオメトリ構造に継承されると規定しています。
• 実際のボトルネック: ドローンやLiDARなどの飛行機器から収集されたデータは、通常、国際座標系WGS84（EPSG:4326）で生データを返します。これをそのまま国内のマップエンジンに投入すると、モデルの位置が数十メートルずれる可能性があります。レンダリングする前に、現在のCRSを特定し、変換ツール（FMEまたはGDAL/ogr2ogrを介して）の構成を設定して、座標をVN-2000平面座標系（例：ハノイの場合はEPSG:3405）に変換する必要があります。

ステップ3: CLI/XPathによるオブジェクトタイプとLODジオメトリのプロファイリング

• アクション: District1_LOD2.gmlやBridge_Data.gmlのようなファイル名を絶対に信用しないでください。ターミナルを開き、xmlstarletまたはgrepを使用して、内部の実際のオブジェクトタグの密度を素早く検査します:Bash# XML名前空間に基づいてオブジェクトの数を数え、分類するコマンド xmlstarlet el hanoi_citygml.gml | sort | uniq -c
• ケーススタディ:
  • ファイル名がBridge_Dataなのに、CLIコマンドが<brid:Bridge>タグを含まず、<bldg:Building>タグばかりを返す場合、3秒以内にファイルを即座に拒否してください。
  • 太陽光発電（ソーラーパネル）の計算が課題の場合、システムは屋根面の傾斜を抽出する必要があります。XPathクエリが<bldg:lod2Solid>または<bldg:RoofSurface>の代わりに<bldg:lod1Solid>（単純な箱型 – 押し出しポリゴン）タグばかりを返す場合、このデータセットは完全に無用です。

ステップ4: 参照整合性の検証

• アクション: Schematronエンジンを使用して、OGCが提供するreferentialIntegrity.schルールセットを実行し、内部のクロスリファレンス関係を自動的にチェックします。
• 理由: 容量を最適化するために、CityGMLではジオメトリ構造を再利用したりテクスチャを貼り付けたりするために、xlink:href属性がgml:idを指すことがよくあります。ベンダーが空間グリッドに従ってファイルを分割する際、リンクが切断され、「デッド」なIDを指すhrefタグが残されることが非常に簡単です。WebGISに表示された際の結果は、モデルの構造が破損したり（壊れたポリゴン）、テクスチャ全体が失われたりすることです。

ステップ5: UUIDのマッピングとユースケースに応じた属性の抽出

• アクション: 課題の分析能力を決定する属性をスキャンして抽出します（例：洪水問題では、地下階の情報を取得するために<bldg:storeysBelowGround>タグをチェックする必要があります）。同時に、gml:idキーの一意性（Unique）をチェックします。
• 実際のボトルネック: 現在、複数のベンダーが作成する3D都市モデルは、「グラフィックは豊富だがメタデータに乏しい」という状況に陥りがちで、基本的な地籍情報が完全に欠けています。XMLファイルにテキスト属性を無理に詰め込もうとすると、ファイルサイズが無駄に膨張するため避けてください。
• 最適な解決策: gml:id自体を主キー（PK）として使用します。CityGML XMLファイルを軽量に保ち（ジオメトリとコア属性のみを保存）、レンダリングパイプラインをスムーズにします。地籍情報や詳細な計画履歴はすべてリレーショナルデータベース（PostgreSQL/PostGIS）に個別に保存し、このUUIDを介して3Dモデルとリアルタイムで結合を実行します。

結論: 構造をマスターすることはパイプラインをマスターすること

CityGMLの構造を検査する能力を習得すれば、ソフトウェアを開いて動作することを祈る必要はなくなります。あなたは入力データの品質を管理し、それが実際の課題の要件を満たしているかどうかを明確に知ることができます。

パート3を読み進める: 次に、CityGMLにおけるLOD（Level of Detail）の概念を深く掘り下げます。これは都市デジタルツインプロジェクトにおいて最も誤解されやすい要素の一つです。問われるべきは、モデルを「より詳細にする」方法ではなく、どのLODレベルが課題に十分であり、なぜ無闇なLODの増加が運用システム全体を崩壊させる罠となるのかということです。