mierune / plateau-gis-converter Goto Github PK

A proof of concept GUI and CLI tool for converting PLATEAU's 3D city models (CityGML) of Japan into various geospatial formats, including 3D Tiles, MVT, and GeoPackage.

Home Page: https://mierune.github.io/plateau-gis-converter/

License: MIT License

Rust 97.74% JavaScript 0.08% CSS 0.02% HTML 0.02% TypeScript 0.55% Svelte 1.36% Python 0.23%

citygml citymodel plateau 3d 3d-tiles geopackage geospatial gis gltf japan

plateau-gis-converter's Introduction

PLATEAU GIS Converter

A proof of concept GUI and CLI tool for converting PLATEAU's 3D city models (CityGML) of Japan into various geospatial formats, including 3D Tiles, MVT, and GeoPackage.

1. 概要

本リポジトリでは、FY2023 の Project PLATEAU「都市デジタルツインの実現に向けた研究開発及び実証調査業務」（内閣府/研究開発とSociety5.0との橋渡しプログラム（BRIDGE））において開発された「PLATEAU GIS Converter」のソースコードを公開しています。

PLATEAU GIS Converter は、PLATEAUが提供するCityGML形式の3D都市モデルを他の一般的なGISデータ形式に変換するソフトウェアです。

東京都23区の CityGML (v2) を読み込んで、3D Tiles に変換した例：

ソフトウェアのメイン画面：

PLATEAU の標準仕様に準拠した CityGML 2.0 形式の3D都市モデルは、専門のGISツールやCLIコマンドを用いて他のGIS形式に変換して用いられることが一般的ですが、一般ユーザーが簡易に利用できる汎用ツールは存在しません。そのため、流通や活用の範囲が専門家や技術者に限られていました。

2. 「PLATEAU GIS Converter」について

「PLATEAU GIS Converter」を利用することで、3D都市モデルを一般的なGIS形式に変換して、様々な分析・開発を行うことができます：

GeoPackage 形式による QGIS 等での解析
Mapbox Vector Tiles (MVT) 形式による、大規模データのWeb等での高速描画
3D Tiles 形式による Cesium 等での可視化
KML 形式による Google Earth での可視化
など

3. 利用手順

ソフトウェアの最新版は、GitHub リポジトリの Releaseページからダウンロードしてください。
詳しい利用方法については、こちらのマニュアルをご覧ください。

4. システム概要

本ソフトウェアの機能は以下の通りです：

3D都市モデル（CityGML）の以下の形式への変換：
- 3D Tiles
- Mapbox Vector Tiles (MVT)
- GeoPackage
- GeoJSON
- Shapefile
- KML
- CZML
複数の入力ファイルをもとにした変換
属性名マッピングルールの取り込み
指定された座標参照系に変換して出力（一部形式で対応）

5. 利用技術

利用技術は以下の通りです。

内部ロジック：

都市モデルの解析および他形式への変換はすべてプログラミング言語 Rust で実装しています。多くの処理はゼロから独自に実装したものです。

ユーザインタフェース (UI)：

デスクトップアプリケーション構築フレームワーク: Tauri
Web UI構築フレームワーク: Svelte

6. 動作環境

本ソフトウェアは以下の環境で動作することを想定しています：

OS:
- Windows 10 以上 (Intel)
- macOS (Apple Silicon, Intel)
CPU:
- 特に制限はありませんが、出力形式や変換するデータ量によっては、CPU性能が処理時間に大きく影響します。
メモリ:
- 特に制限はありませんが、出力形式や変換するデータ量によっては、変換時に多くのメモリを要します。
ネットワーク:
- インターネット接続は不要です。
ストレージ:
- インストールには30MB程度の空き容量が必要です。
- データ変換時には、変換元データと同等ないしそれ以上の空き容量が必要です。

7. 本リポジトリのフォルダ構成

アプリケーション：
- app — Tauri による GUI 実装
- nusamai — アプリケーションバックエンドおよびコマンドライン版の実装
データソース：
- nusamai-citygml — CityGML パーサ実装支援ライブラリ
  - macros — パーサ導出用の proc macros
- nusamai-plateau — PLATEAU 用の CityGML モデルおよびパーサ
基盤・ユーティリティ（本プロジェクトのユースケースと癒着しないように構成）：
- nusamai-projection — 投影法変換
- nusamai-mvt — Mapbox Vector Tiles (MVT)
- nusamai-gpkg — GeoPackage
- nusamai-gltf — glTF
- nusamai-geojson — GeoJSON
- nusamai-kml — KML
- nusamai-czml — CZML
- nusamai-shapefile — Shapefile

7.1. 外部リポジトリ

MIERUNE/earcut-rs — ポリゴン三角形化アルゴリズムのRust移植
MIERUNE/japan-geoid — 日本のジオイドモデル (JGD2011 → WGS 84 の変換)
MIERUNE/flatgeom-rs — シリアライズ/デシリアライズの効率を優先したジオメトリ型
MIERUNE/kv-extsort-rs — Key-value データの外部ソート
MIERUNE/dda-vozelize-rs — 3Dメッシュサーフェスの高速なボクセル化
MIERUNE/cesiumtiles-rs — 3D TilesのJSONモデルなど

8. ライセンス

本ソフトウェアは、MITライセンスのもとで提供されるオープンソースソフトウエアです。
ソースコードおよび関連ドキュメントの著作権は国土交通省および開発者に帰属します。
本ソフトウェアの開発は株式会社MIERUNEが行っています。

9. 注意事項

本リポジトリおよびソフトウェアは Project PLATEAU の参考資料として提供しているものです。動作の保証は行っておりません。
本リポジトリおよび本ソフトウェアの利用により生じた損失及び損害等について、開発者および国土交通省はいかなる責任も負わないものとします。
本リポジトリの内容は予告なく変更・削除する場合があります。

10. 参考資料

Development (開発者向け情報)

Build & Run

CLI

cd ./nusamai/
# Debug (非常に低速)
cargo run -- ~/path/to/PLATEAU/15100_niigata-shi_2022_citygml_1_op/udx/bldg/*.gml --sink geojson --output foobar.geojson
# Release (最適化コンパイル)
cargo run --release -- ~/path/to/PLATEAU/15100_niigata-shi_2022_citygml_1_op/udx/bldg/*.gml --sink geojson --output foobar.geojson
# Release (LTO有効のプロダクションビルド、最高速)
cargo run --profile release-lto -- ~/path/to/PLATEAU/15100_niigata-shi_2022_citygml_1_op/udx/bldg/*.gml --sink geojson --output foobar.geojson

GUI

Dev:

cd ./app/
npm install
RUST_BACKTRACE=1 npx tauri dev

Build:

cd ./app
npx tauri build

Test

Test & Lint

cargo clippy --all-targets --all-features
cargo test --workspace --exclude app --all-features

Coverage

Codecov: https://app.codecov.io/gh/MIERUNE/plateau-gis-converter

cargo llvm-cov --workspace --exclude app --html --all-features

plateau-gis-converter's People

Contributors

Stargazers

Watchers

Forkers

project-plateau mapconcierge reearth fossabot tossetolab

plateau-gis-converter's Issues

なるべく効率の良いFeatureOrData.geometriesの使い方を考える

TopLevelCityObject.geometriesは親地物の形状をすべてまとめて保持しているため、子要素の地物ごとに属性を付与する場合に適合しにくい
TopLevelCityObject.rootのFeatureOrData.geometriesにはGeometryRefが格納されており、これは子要素ごとの頂点の参照を持っているので、これを利用する方が良い
ただし、あくまで参照しているだけなので、使いづらい状態
GeoJSON・GeoPackage・glTF（など）への出力する際に共通で利用できるようなインターフェースを用意できると良い

CI: cargo doc → GitHub Pages

最新のドキュメントがWeb上で見れると少し便利。

geometry: 破綻したデータ構造を簡単に作れないようにする

現状の Polygon::new や MultiLineString::new は入力された生データをそのまま受理するため、これらを使って不正な内部データを容易に構築できる。

破綻したデータを簡単に作れる例：

    #[test]
    #[should_panic]
    fn test_polygon_invalid_hole_indices_2() {
        let all_coords: Vec<f64> = (0..=2).flat_map(|i| vec![i as f64, i as f64]).collect();
        let hole_indices: Vec<u32> = vec![99]; // out of `all_coords` range
        let polygon: Polygon2<f64> = Polygon2::new(all_coords.into(), hole_indices.into());

        polygon.exterior(); // panic, as `all_coords[0..hole_indices[0]]` is invalid
    }

改善案

new は default (空ジオメトリを作る) と同じ挙動にする。
生の coords, hole_indices からデータを組みたい利用者に向けては from_raw(_checked) (safe), from_raw_unchecked (unsafe) のような初期化メソッドを用意する。

PLATEAUモデル: 都市計画決定情報

#47 と同じように、属性を定義する必要がある
しかし、都市計画決定情報の色々な種類のものが、似た属性を持っている
なので、愚直に全部を書き下すこともできるが、共通部分をうまく括り出せると良い
しかしそれには、パーサーの改修も必要

gen:genericAttribute を扱えるようにする

以下のような汎用属性を扱えるようにする（パース、出力、etc. できるようにする）：

gen:dateAttribute
gen:doubleAttribute
gen:genericAttributeSet
gen:intAttribute
gen:measureAttribute
gen:stringAttribute
gen:uriAttribute

CityGML 2.0 ではこれらは Feature の直下に記述されるが、CityGML 3.0 では core:genericAttribute (PropertyType) で包むようになった（下図）。我々のモデルも内部的には3.0の思惑に寄せておく（？）のがよいだろう。

3D Tiles 用の各種JSONモデルを作成

glTF: #16 を参考

JGD2011 Geographic 3D → WGS84 Geographic 3D → WGS84 Geocentric 3D の変換

少なからぬ場所で以下のCRSの変換が必要。実装する。

JGD2011 Geographic 3D (EPSG:6697) → PLATEAUの元データ
WGS 84 Geographic 3D (EPSG:4979, EPSG:4326) → GeoJSONなどの一部の形式は座標が WGS84 であることを要求する
WGS 84 Geocentric 3D (EPSG:4978) → 3D Tiles

JGD2011平面直角座標系からの変換（逆方向も？）

必要なら実装する。

参考：

PROJ: https://github.com/OSGeo/PROJ/blob/master/src/projections/tmerc.cpp （Gauss-Krugerは横メルカトル図法の一種）
- exact (Knud Poder/Karsten Engsager) なアルゴリズムと approximate (Gerald Evenden/John Snyder) なアルゴリズムが実装されている。PROJのデフォルトは exact 。
- PROJ以外のちまたの実装は後者の approximate のアルゴリズムであることが多そうなので注意。

>>> import pyproj
>>> tg = pyproj.transformer.TransformerGroup("6676", "4326")
'+proj=pipeline
+step +proj=axisswap +order=2,1
+step +inv +proj=tmerc +lat_0=36 +lon_0=138.5 +k=0.9999 +x_0=0 +y_0=0 +ellps=GRS80
+step +proj=unitconvert +xy_in=rad +xy_out=deg
+step +proj=axisswap +order=2,1'

MultiLineString, MultiPointへの対応

#89 の実装では、MultiPolygonのみに対応していた。

トップレベル都市オブジェクトは、他にMultiLineString, MultiPointも持ちうる（が、データとしてはほとんどない模様）。

JGD 2011 → WGS 84 の変換（をどこで行うか）

多くの形式において JGD 2011 → WGS 84 の変換（ジオイドモデルの適用）が必要になる。

変換をどこで行うべきか

Transformer で行う
or 出力層が各自で行う

多くの出力形式で共通して必要になる処理なので、Transformer で行うのがよいように見える。

ただし、「JGDのまま出力したい」などの要望がありそうなので、それに対応できる作りにしておくべきか。

nusamai-gpkg: 属性の取り扱い

#89 で実装したものでは、ジオメトリのみを追加した。

GeoPackageの実態がRDBである性質上、柔軟な対応が可能と考えられる。

GeoPackageに限らず、他のファイル形式での属性の取り扱い（特に入れ子のもの）とも協調して進める。

Codecov: patch の条件を緩和する

codecov/patchが ❌ になることが多い。条件を緩める。

データ構造のドキュメント

#5 で実装したものの解説を書く。図解もあるとなおよし。

実装担当した @ciscorn ではなく、第三者がやると良い。

crateのREADMEを書くと良い想定。

コード内ドキュメントも、公開を見据えて合わせて英語化しても良いかもしれない（別PR？）

CityGML: codelist (CodeType) の値を解決できるようにする

CityGMLには gml:CodeType という要素型があり、具体的な値を、代わりの整数値などで表現するために使われる。

例えば以下のような要素において、

<uro:lod1HeightType codeSpace="../../codelists/BuildingDataQualityAttribute_lod1HeightType.xml">2</uro:lod1HeightType>

値 "2" が示す意味は、../../BuildingDataQualityAttribute_lod1HeightType.xml に記述されている。

この値を解決する処理を実装する必要がある。 QGISプラグイン用Python実装にもこの処理が実装されている。

タスク

初期的実装をする
設計・実装を洗練する

nusamai-gpkg: Sinkの追加

#89 でのミニマムな実装をもとに、GeoPackage用のSinkを用意する。

参考: GeoJSONでの対応例 - #87

これにより、CLIで、CityGMLファイルをGeoPackageへ変換して出力することも可能になる。↓のようなイメージ

$ time cargo run --release plateau/22203_numazu-shi_2021_citygml_4_op/udx/bldg/*.gml --sink gpkg

施設管理と公共測量標準図式の応用スキーマを正しく扱う

施設管理の応用スキーマまわり (uro:FacilityIdAttribute, uro:FacilityAttribute) と公共測量標準図式の応用スキーマまわり (uro:DmAttribute) について、これらの型の多態性を正しく解釈してモデルを実装する必要がある。

施設管理まわり (uro:Facility*) と公共測量標準図式まわり（uro:Dm*) の土台を作る
- #82
施設管理まわり (uro:Facility*) と公共測量標準図式まわり（uro:Dm*) を詳細に実装する
これらについてのテストを追加する

以下メモ：

uro:FacilityIdAttribute は、かわりに下位型の uro:RiverFacilityIdAttribute 型のデータが与えられる可能性がある。
uro:DmAttribute は、実際には下位型の以下のいずれかになる（uro:DmAttribute 自体は抽象型なので存在できない）。
- uro:DmAnnotation
- uro:DmGeometricAttribute
uro:FacilityAttribute は、実際には下位型の以下のいずれかになる（uro:FacilityAttribute 自体は抽象型なので存在できない）。
- uro:CargoHandlingFacility
- uro:CyberportMarinaAndPBS
- uro:FishingPortAttribute
- uro:FishingPortCapacity
- uro:FishingPortFacility
- uro:HarborFacility
- uro:MaintenanceHistoryAttribute
- uro:MooringFacility
- uro:NavigationAssistanceFacility
- uro:PortAttribute
- uro:PortEnvironmentalImprovementFacility
- uro:PortManagementFacility
- uro:PortPassengerFacility
- uro:PortPollutionControlFacility
- uro:PortProtectiveFacility
- uro:PortStorageFacility
- uro:PortTransportationFacility
- uro:PortWasteTreatmentFacility
- uro:PortWelfareFacility
- uro:ShipServiceFacility

住所 xal:Address を扱えるようにする

bldg:Address などの住所は OASIS extensible Address Language (xAL) で記述される。

複雑な構造を持つ。

これをどのように扱うかの判断が必要なので、特に要求されなければ急いで実装しないほうが良いかもしれない。

PLATEAUモデル: 4.4交通（鉄道）

relate #165

ジオイドモデルの埋め込みを include_bytes! にする

1ファイルを埋め込むだけなので rust_embed は要らない

GeoJSONのsinkを作成

#78 で用意された形に合わせて、 #79 で実装したGeoJSON変換処理を使う。

これにより、以下のように処理できるようになる:

cargo run --release plateau/*.gml --sink geojson

4.25.3　施設管理属性の応用スキーマのテスト

モデルの実装
テスト

relate #165

glTF 2.0 のモデルをレビューする

glTFモデルは、公式の JSON Schema (https://github.com/KhronosGroup/glTF/tree/main/specification/2.0/schema) をもとに機械的に雑に生成したものが多いので、内容を目視でひとしきりチェックしておきたい。

https://github.com/MIERUNE/nusamai/tree/main/nusamai-gltf/src/models

デフォルト値の扱い。
型付け
etc.

PLATEAUモデル: 都市設備（CityFurniture）

nusamai-plateau 内で、都市設備モデルを定義する。

標準製品仕様書: https://www.mlit.go.jp/plateaudocument/#toc4_14

都市設備とは、都市の屋外（道路、住宅街、広場、造成地等）に設置されている、移動しない小規模な設備である（例：街路灯、道路標識、交通信号機、花壇、広告板、ベンチ、境界杭、バス停）。

CI (GitHub Actions) でのテストの高速化

諸々の事情によりCIでのテストが遅くなっている。何らかの対処が必要。

間接的な原因：

monorepo であること。
- 特に Tauri が居ること。Tauriと共に全体のテストをするとビルドアーティファクトが肥大化するよう？
今回は基盤ライブラリ的なコンポーネントも自作しているが、それらも monorepo に入れていること。
- さらに、それらのコンポーネントには、テスト用に巨大な fixtures を必要とするものが多いこと。
ビルドキャッシュがうまく効いていない場合が多々あるかもしれない。
その他の原因

解決案いくつか：

ビルドキャッシュ周りの見直し。
テストワークフローを分ける。pull requestでは、変更されたコンポーネントのテストしか回さない。
- 特に巨大な tauri とそれ以外を切り分ける。
汎用性の高いモジュールは、別のリポジトリとして切り離す。
性能のよいRunnerを使う。
etc.

CityGMLモデル定義からスキーマ情報を出力する仕組み

一部の出力フォーマットにおいては、データを流し込む前に、データモデルのスキーマを把握する必要がある（例： GeoPackageにおいてSQLiteのテーブルを作る）。

CityGML モデル (CityGMLElement) に対して、何らかのスキーマ情報を自動生成する仕組みを設ける。

ObjectifyされたデータをglTFへ出力する部品

nusamai/src/sink/geojson.rsを参考にnusamai/src/sink/gltf.rsを実装する
cargo run --release plateau/22203_numazu-shi_2021_citygml_4_op/udx/bldg/*.gml --sink gltfのようなコマンドで変換が実行できることを目標とします
テクスチャの前に、まずは形状のみで良いので、変換できるようにしたいです
nusamai-gltf/src/modelsを利用して変換していきたいです

3D Tiles 2.0 のための glTF 拡張機能に対応する

glTFのJSONパートのモデルを拡張して、3D Tiles のための以下の拡張機能に対応できるようにする。

番外編として以下も必要か？

(KHR_materials_unlit): 光源の計算をしないベタ塗りマテリアル指定。

巷にあるRust用の「glTF読み込み専用ライブラリ」は、feature flags で拡張機能用フィールドの有効無効を切り変えられるようにしてあるように見える。

Option型のpropertiesの取り扱いを検討・修正

#90 ではnullのプロパティは無視され、出力からは省略されていた
QGISプラグインではnullのプロパティはnullであることが明示される

全部出してくれと言われる可能性が高いので、修正予定

nusamai-gpkg: 座標系の取り扱い

related #89

現在の実装（ #89 ）では、 4326 とベタ書きしている。

必要に応じて、これを変える。

必要なもの

gpkg_spatial_ref_sys テーブルでの、座標系定義
- 現在は sql/init.sql に、ミニマムの三種類、書いてある
gpkg_contents テーブルでの指定（ srs_id カラム）
gpkg_geometry_columns テーブルでの指定（ srs_id カラム）
地物バイナリのヘッダー
- 現在は geometry.rs の geometry_header(srs_id: i32) で、指定できるようになっている

出力ドライバー: geojson - 2次元への変換

3次元の情報を、2次元に落とす。

QGISプラグインではオプションがあったはず。

単にzの値を除去するだけでよい？

経緯度の順番をlon,latへ整理

PLATEAUデータでは lat, lon, altitude
GeoJSONなどで求められるのは lon, lat, ...

#75 では、GeoJSONクレート内でやろうとしたが、より最初の段階で、整理していた方が良い。他の出力形式でも概ねその方が良さそう。

GeoJSONでの属性の取り扱い

#3 , #42 を元にした、 nusamai-geojson での属性の取り扱いを検討・設計・実装する。

地物を意味的子要素に分割して保持する

#118 の前にまずはGeometryRefからポリゴンの再構築や属性の保持などを行えるように実装してみる

uro:BuildingDetailAttributeやuro:BuildingDisasterRiskAttributePropertyなどの話
QGISプラグインではgml-idでリレーションを組んで、図形無しの別レイヤーとして出力していた
どちらの属性もbldg:Buildingに紐づいているので、子要素の図形には紐づかないはず
- よって、LOD4建物などの場合でも、親の建築物に紐づく
表形式で出力しなければいけないGISデータでは同様の対応が必要そう

CityGML → MultiPolygon (実験用)

CityGMLから「雑に」適当なジオメトリを読むコードを書く。

ジオメトリの読み込みから出力までをひとまず一気通貫でやりたいという話があり、その実験用に使う。

実際のプロダクトで使うことを意図したものではない。

MVT: (z, x, y) と1次元のタイル番号を相互変換する処理

地物をタイルごとにまとめ上げるために、タイル座標 (z, x, y) を1次元の整数 tile_id にする処理が必要になる。

planetiler は以下の2種類の方法を実装している：

https://github.com/onthegomap/planetiler/blob/main/planetiler-core/src/main/java/com/onthegomap/planetiler/geo/TileCoord.java

Hilbert: ヒルベルト曲線に基いた Id（PMTilesのTileIdに準拠）
- そのままPMTilesへの出力順としても使える。
- 入力データの空間的な特性により、無駄なソートが減って速いかもしれない。
TMS: z, x, y を単純にビット演算で詰めたようなもの。Planetilerでは z (4bits), x (14bits), y (14bits) 。
- 計算が単純なため tile_id の計算は速いかもしれない。

事象

#56 で、都市設備（CityFurniture）をパースしようとしていた
- テスト
  - nusamai-plateau/tests/test_cityfurniture.rs
  - テストデータ: 沼津市
**=> エラー: Err: SchemaViolation("Unexpected element <MultiGeometry>") **

調査

データ

52384698_frn_6697_op.gml

↓のように記述されている:

...

	<core:cityObjectMember>
		<frn:CityFurniture gml:id="FRN_16309dc7-9bf6-49e5-a18d-c4e739f1226b">
			<frn:class codeSpace="../../codelists/CityFurniture_class.xml">1000</frn:class>
			<frn:function codeSpace="../../codelists/CityFurniture_function.xml">1010</frn:function>
			<frn:lod3Geometry>
				<gml:CompositeSurface>
					<gml:surfaceMember>
						<gml:Polygon gml:id="fme-gen-2462f156-9328-4710-a18e-534219033483">
							<gml:exterior>

...

モノによっては、↓のように、 <gml:MultiGeometry> が使われている:

...

	<core:cityObjectMember>
		<frn:CityFurniture gml:id="FRN_d95d8062-598b-4f99-8cd5-8da840637b58">
			<frn:class codeSpace="../../codelists/CityFurniture_class.xml">1000</frn:class>
			<frn:function codeSpace="../../codelists/CityFurniture_function.xml">2000</frn:function>
			<frn:lod3Geometry>
				<gml:MultiGeometry>
					<gml:geometryMember>
						<gml:CompositeSurface>
							<gml:surfaceMember>
								<gml:Polygon gml:id="fme-gen-92c0bd59-9dbc-488d-aabf-0fd3b0c95645">
									<gml:exterior>

...

パーサーのコード

https://github.com/MIERUNE/nusamai/blob/8c3e0b200f7f4555542b6c9f5338be4febd6a89d/nusamai-plateau/citygml/src/parser.rs#L302C1-L328C23

                    let (nsres, localname) = self.reader.resolve_element(start.name());
                    let poly_begin = self.state.geometry_collector.multipolygon.len();

                    let geomtype = match (nsres, localname.as_ref()) {
                        (Bound(GML_NS), b"Solid") => {
                            self.parse_solid()?;
                            GeometryType::Solid
                        }
                        (Bound(GML_NS), b"MultiSurface") => {
                            self.parse_multi_surface()?;
                            GeometryType::Surface
                        }
                        (Bound(GML_NS), b"CompositeSurface") => {
                            self.parse_composite_surface()?;
                            GeometryType::Surface
                        }
                        (Bound(GML_NS), b"OrientableSurface") => todo!(),
                        (Bound(GML_NS), b"Polygon") => todo!(),
                        (Bound(GML_NS), b"TriangulatedSurface") => todo!(),
                        (Bound(GML_NS), b"Tin") => todo!(),
                        _ => {
                            return Err(ParseError::SchemaViolation(format!(
                                "Unexpected element <{}>",
                                String::from_utf8_lossy(localname.as_ref())
                            )))
                        }
                    };

CityGML の仕様

OGC City Geography Markup Language (CityGML) Encoding Standard

↓の図に、MultiGeometryが示されている。

現状では、生身のgeometryを入力している
→ その後に #3 や #42 で作られた形に合わせる

CityGMLElement型の proc macros を改善する

共通フィールド (e.g. @gml:id, gml:name, etc.) の自動挿入
Feature (w/ geom), Data (w/o geom), Property (多態性用enum), etc. などごとに attribute macro を用意する
- #[derive(CityGMLElement) を直接使わないようにすることで、ガイドライン/ガードレールを引く
- 今後、Feature や Data の違いを区別するための余地を与える

入れ子になった子要素の地物にも属性を付与する方法を検討

QGISプラグインではいくつかのオプションがあった
- 「最も単純なLODのみを読み込む」: LODが低いもののみを読み取る
- 「最も詳細なLODのみを読み込む」: LODが高いもののみを読み取る
- 「全てのLODを読み込む」: 地物の中にあるLOD0~4まで全て読み込み、LODごとにレイヤを分割する
さらに、「地物を構成する部分ごとにレイヤを分ける」を設定するとLODごとに、かつ要素ごとにポリゴンが分かれる
子要素は大した属性を持っていないことが多いが、要素ごとに属性を付与することは必須
3DTilesでは最も詳細な地物ごとに分割し、属性もポリゴンごとに付与したいが、GeoJSONでは親の地物にだけ属性が付与されていればいいか…など、QGISプラグインと同様に状況によって出力は変更出来るようにした方が良さそう
データ作成実証_CityGML/13100_tokyo23-ku_2022_citygml_1_lod4-2_op/udx/bldg/53393680_bldg_6697_lod4.2_op.gmlを読み込んでみた結果、カラムに入れ子のJSONがそのまま読まれているような状況

FeatureOrData を Feature と Data に分ける

これらは CityGML の "Stereotype" とされている <<Feature>> と <<Data>> にもとづいている。

Feature: 地物っぽいもの（@gml:id, gml:name, etc.をもつもの）。
Data: idをもたない「データ」。

いっしょくたに扱っていたが、ツリー構造展開時の扱いなどを考えて、両者を判別できるほうがよいかもしれない。

CityGML 3.0 には <<Object>> という Stereotype もある。