cjdbを紹介します：3D都市モデルへのシンプルなアプローチ

3D都市モデルをデータベースに保存するのはちょっと大変だよね。よく使われる方法の一つにCityGMLっていうシステムがあって、複雑なテーブルの設定が必要になることもあるんだ。例えば、よく使われる3DCityDBは、データを管理するのに66のテーブルが必要なんだ。

この記事では、'cjdb'っていう代替のデータベースソリューションを紹介するよ。これを使うとPostgreSQLでCityGMLモデルをもっと簡単に保存できるんだ。3DCityDBがたくさんのテーブルを必要とするのに対して、cjdbはたった3つのテーブルしかいらない。このシンプルさは、都市オブジェクトの詳細をJSONっていうフォーマットで保持することで実現してるんだ。

私たちのアプローチはCityJSONを使っていて、これは3D都市モデルの情報を保存するために設計されたものなんだ。cjdbの目標は、ユーザーが複雑な構造に迷わずに3D都市データを扱えるようにすることなんだ。

#cjdbのメリット

cjdbを3DCityDBと比較して、大きな実世界の3D都市モデルを使ってテストしたら、いくつかの大きな違いが分かったよ。まず、cjdbはかなり少ないスペースしか取らない – 3DCityDBの約10分の1なんだ。これは、同じデータ量を保存するのに必要なストレージが少なくて済むってことだね。

次に、cjdbはデータのインポートとエクスポートの速度が速いんだ。ユーザーはデータをデータベースに出入りさせるのが早くできるし、データを取り出すときは両方のシステムで速度は似てるけど、cjdbではいくつかのクエリが速かったり、逆にちょっと時間がかかったりすることもあるよ。

データのインポートとエクスポートを可能にするソフトウェアは、オンラインで無料で入手できるよ。

#CityGMLって？

CityGMLは都市のデジタルモデルを保存するための国際的な標準なんだ。これを使うと、建物や道路、木、橋など、都市エリアにある一般的な3Dオブジェクトを定義して保存できるんだ。また、これらの3Dオブジェクトには異なる詳細度（LoD）をサポートしてるから、いろんなアプリケーションに便利だよ。

CityGMLは詳細な構造を持ってるけど、データをデータベースで管理する必要があるときには課題が出てくることもある。そこでcjdbが登場して、同じデータを扱うのにもっと簡単な方法を提供してるんだ。

#データベース管理システム（DBMS）

大きなデータセットの管理は特に重要だよ、特に都市モデルの場合ね。データベースは大規模な情報を保存・管理する効果的な方法を提供してるんだ。単純なファイルシステムよりも、セキュリティやバージョンアップの簡単さ、スケーラビリティの向上など、いくつかの利点があるんだ。

3DCityDBは膨大な都市データを扱うのに人気があって、複数のユーザーがアクセスできるんだ。通常、ユーザーはデータをリモートサーバーに保存してウェブインターフェースを通じてアクセスする必要があるから、情報がたくさんのテーブルに分かれちゃうから面倒なんだよね。

#3DCityDBの課題

3DCityDBは広く使われてるけど、多くのユーザーが扱うのが難しいと感じてるんだ。一番の問題は、データが66のテーブルに分散してるから、情報を結合するのに複雑なクエリが必要になることなんだ。

これを簡単にするために、よりシンプルなアクセスのための追加のビューを作る試みもあるけど、逆にデータベースのサイズが大きくなることもあるんだ。

#cjdbへの移行

3DCityDBの複雑さに対応するために、cjdbが開発されたんだ。これは3つのテーブルだけを使う、もっとシンプルなスキームなんだ。これによって、ユーザーは複雑なテーブルやクエリの結合に頭を悩ませずに3D都市モデルを効率的に保存・取り出せるんだ。

cjdbの主な特徴は、ジオメトリや属性をJSON形式で直接扱うことなんだ。これによって、必要なスペースが減って、データのインポートとエクスポートが速くなるんだ。

#cjdbのデータモデル

cjdbのデータモデルはシンプルフィーチャーアプローチにインスパイアされてるんだ。都市オブジェクトテーブルの各行にはCityJSONオブジェクトが保存されてて、ジオメトリは一つのカラムに保存されてる。これによって、ユーザーは都市データを簡単に管理・処理できるんだ。

各都市オブジェクトには識別子、タイプ、属性、ジオメトリが含まれてて、すべてが一つのカラムにきれいに収められてるんだ。さらに、オブジェクト同士の関係は別のテーブルで追跡されてて、クエリを助けてるよ。

データベースにはインポートされたCityJSONファイルのメタデータも含まれてて、座標参照系やバウンディングボックスなどの重要な要素が記録されてるんだ。

#パフォーマンス比較

cjdbが3DCityDBと比べてどれくらい性能が良いかテストするために、3つの異なる地域の情報を使ってベンチマークデータセットを作ったよ。両方のシステムにデータをインポートして比較したんだ：

• インポートとエクスポート時間：cjdbは一般的に速かったよ。例えば、あるデータセットから100タイルをインポートするのに、cjdbは21秒、3DCityDBは113秒かかったんだ。

• データベースのサイズ：cjdbは3DCityDBよりもずっと少ないスペースが必要だった。サイズの違いは、二つのシステムが機能を保存する方法に起因してるんだ。3DCityDBでは、壁や屋根のような面が別々のオブジェクトとして扱われるけど、cjdbではそれらを一つのオブジェクトにまとめて保存してるんだ。

• データ取り出し速度：一般的なSQLクエリを使って、各システムがどれくらい速くデータを取り出せるか測定したんだ。全体的に、cjdbはシンプルな構造のおかげで多くの2Dクエリでより良いパフォーマンスを示したよ。これによって、3DCityDBに必要な複雑な結合を避けられるんだ。

#クエリの詳細

パフォーマンスを評価するために8種類のクエリを調べたよ：

1. 属性ベースのクエリ：いくつかの属性ではCJDBが3DCityDBより速かったけど、他の属性では時間が似てたよ。

2. 2D空間クエリ：cjdbは2D空間クエリに強くて、3DCityDBの複雑な結合なしで簡単にデータを取り出せたよ。

3. 部品のカウント：速度はデータセットのサイズによってもっと変わったけど、cjdbはシンプルなクエリを使うと有利だったね。

4. 詳細度（LoD）クエリ：cjdbは特定のLoDクエリでは遅いこともあるけど、ジオメトリも必要な場合は、3DCityDBの結合が必要な分、早くデータを取得できるよ。

5. 属性の変更：データベースへの追加はcjdbではちょっと遅いけど、JSON形式の変更に時間がかかるから。ただし、更新や削除はcjdbの方が効率的だったんだ。

#結論と今後の取り組み

cjdbプロジェクトは、ユーザーが3D都市モデルを保存・扱うのをもっと簡単にすることを目指して、複雑さを減らすことを狙ってるんだ。3つのテーブルだけで運用できるから、3DCityDBよりずっとシンプルだし、JSONのようなフォーマットでデータを保存することで、インポートとエクスポートのプロセスが早くなるんだ。

cjdbは2D空間クエリでのパフォーマンスが良いけど、JSONカラムを変更したり、多くの属性がある場合には課題も抱えてる。今後のステップとしては、意味的な表面からジオメトリを抽出する関数を開発したり、クエリや視覚化のためのより良いツールでユーザー体験を改善することが目標なんだ。

テクスチャや材料のサポートを拡張して、データベースの能力を強化する計画もあるよ。3D都市モデリングの分野が進化する中で、cjdbはユーザーのニーズや技術の進歩に対応し続けて、都市データ管理のための貴重なツールであり続けることを目指してるんだ。