３次元空間情報基盤アーキテクチャ設計
報告書
2022年 7月
経済産業省／デジタルアーキテクチャ・デザインセンター（DADC）

報告書目次1

本プロジェクトの検討背景

P03

２

本プロジェクトが目指すビジョン

P11

3

ユースケースの検討

P15

4

空間の定義

P31

5

3次元空間情報基盤のアーキテクチャ検討

P52

6

今後の検討事項P75

APPENDIX

P83
Copyright © 2022 METI / IPA

2

1

本プロジェクトの検討背景

1-1 デジタル庁依頼に基づく自律移動モビリティのアーキテクチャ設計
1-2 自律移動ロボットプログラムに関するＤＡＤＣの体制
1-3 デジタルツインの整備と本ＰＪの範囲
1-4 自律移動ロボットプログラムの主なスケジュール
1-5 現状の課題認識
1-6 本プロジェクトにおける検討事項

3

1-1 デジタル庁依頼に基づく自律移動モビリティのアーキテクチャ設計
デジタルを前提として再設計された商品・サービスにより、過去の延長線上で商品・サービスを提供する事業者の売上は低迷している。デジタル庁より次の成長産業である自律移動モビリティのアーキテクチャ設計依頼をうけ、DADCではデジタルを前提とした将来ビジョンからバックキャストして検討を進めている。
自律移動モビリティ検討の必要性
ユーザー
体験の質

デジタルを前提として商品・サービスを再設計し、良質なユーザー体験を提供
過去の延長線上
で商品・サービスを提供
時間

自律移動モビリティの検討方針
自律移動モビリティが富みを創出するために、将来ビジョンを描き、将来ビジョンからバックキャストしてIoTシステム、ルールのあり方を検討

将来ビジョン
将来ビジョン実現に必要な取組を追加

ギ

バックキャスト ャ

人間の作業の効率化

ップ

例えば携帯電話では、過去の延長線上での商品・サービス提供により、海外にシェアを奪われてしまい、売上は低迷。
自律移動モビリティは次の成長産業であり、デジタルを前提とした社会・ビジネスの再設計が必要

自律移動ロボットとデジタルで...

フォアキャスト
2020年代中頃

2030年代頃

社会的課題を解決しながら•富を創出•
人間の生活を豊かに

Copyright © 2022 METI / IPA

4

参考：デジタル庁からＤＡＤＣに対するアーキテクチャ設計の依頼文
情報処理の促進に関する法律に基づき、デジタル庁からDADCに対して、自律移動ロボットのアーキテクチャ
設計について検討を依頼。当該依頼を踏まえて、DADCは、経済産業省の支援のもとで、検討体制を構築した。
• 自律移動ロボットのうち無人航空機及び車両（以下「無人航空機等」という。）について、我が国において中長期的には年間500万フライトを上回るなど活用
され、社会的課題の解決や産業の発展につながる将来像を具体化し、その実現に必要なベース・レジストリ、三次元空間地図、運行管理システム、飛行・運
転制御システム、機体等状態管理システム、取得情報分析システムなど、運用及び管理を行う者が異なる複数の関連する情報処理システムとの連携の仕組
み（アーキテクチャ）を描いて令和４年７月までに提出し、その後、整備すべきデータ連携基盤の具体の仕様を作成すること。

• その際、①無人航空機等及び周辺環境に関するデータの収集及び伝達の仕組み（三次元空間地図を相互にリファレンス可能とするために必要な基準の設定、三次元空間地図のリアルタイム性の確保やリアル タイム性を確保できない場合の代替となる仕組み、自律移動ロボットの利用者や所有者 を認証する仕組
み、自律移動ロボットが互いを認識するためのID 等の仕組み、鳥や有人機等のリアルタイムでの飛行情報を把握する仕組み、様々な運行システムの運用を前提 とした際に必要な標準通信規格の特定、API やデータフォーマットの仕様の具体化、脆弱 性情報、飛行禁止・停留可能区域情報、障害物情報（信号機、標識、電柱・電信柱の位置・ 形状、送配電線など）、通信環境情報（ある空間においてLTE が使用できるかどうか等）、運行者情報、資格情報、機体情報（空間座標、機種、ソフトウェアバージョン、電池残量、LTE 通信（操縦・映像伝送）の可否など）、インフラメンテナンス関連情報（点検・修繕の計画・報告・修繕に関する情報など）、農業関連情報（播種、施肥、農薬散布、害獣監視、生育状況、収穫量に関する情報など）、物流関連情報（集荷、配達、所要時間に関する情報など）のデータ収集・伝達の仕組み等）を含めた無人航空機等を利用するためのデジタ ルインフラ、• ②自律移動ロボットを取り巻く環境の変化に柔軟にデータ連携基盤を対応させるために必要な、環境・リスク分析、ゴール設定、システムデザイン、運用、評価、改善といったサイクルを、マルチステークホルダーで継続的かつ高速に回転させていくための仕組み、• ③既に存するデータやシステムの実態を踏まえデータ入力・連携を可能な限り簡易に行えるようにするとともに、データ連携基盤を通じた運用がタイムラグなどを生じずに軽快に行えるようにするなど、データ連携基盤を使用するユーザーのユーザービリティを向上するための仕組み、• ④プライバシーやサイバーセキュリティを確保（機微な情報の漏えい防止、データの悪用防止、データ改ざん等によるシステム全体への影響の防止等）するための仕組みについても検討を行うこと。

• また、無人航空機等に関するISO 規格や米国ASTM規格など国際基準・標準の動向を把握し、整合を図ること。

Copyright © 2022 METI / IPA

5

1-2 自律移動ロボットプログラムに関するＤＡＤＣの体制DADCでは、自律移動ロボットプログラムを立ち上げ、その中に３つの領域のプロジェクトを編成し、併せて有識者の協力を得て各領域の検討会を組織した。

全体

運行

共通デー
タ

IoT
インフラ

将来ビジョンＰＪ ＠ ビジョン検討会 ※自律移動ロボット将来ビジョン検討会※以下の3つの検討会での検討内容はビジョン検討会に報告する。
ドローンＰＪ ＠ ドローンアーキテクチャ検討会

サービスロボット※ビジョン検討会で議論

その他モビリティ※ビジョン検討会で議
論

3次元空間情報基盤ＰＪ ＠ ３次元空間情報基盤アーキテクチャ検討会

政府保有データ

民間保有データ※３次元空間情報基盤アーキテクチャ検討会で議論※３次元空間情報基盤アーキテクチャ検討会で議論

IoTインフラ※ビジョン検討会で議論

Copyright © 2022 METI / IPA

6

1-3 デジタルツイン（現実世界をデジタル空間上に再現）の整備と本ＰＪの範囲
安全性を保ちながら大量・高頻度・高密度の運行を実現するためには、空間情報や事故情報等を動的（時間軸）かつ詳細（空間軸/意味軸）に捉えて、サイバー空間上で自動的にリスク評価や安全性評
価・認証を行い、安全な運行経路や機体・関係システムが活用されるようにすることが重要。
フィジカル空間

空間情報や事故情報等を同期

機体・関係システムの安全性評価・認証

運行経路の安全性のリスク評価

サイバー空間シミュレータ
部品モデル
運用データ

異なる基準に基づいた空間情報であっても一意に特定できる三次元空間IDを検索キーとして導入し、鮮度の高い様々な空間情報を高速に自動結合できた
り、簡単に検索可能にする。

３次元空間情報基盤プロジェクトの担当範囲

機体モデル

運行モデル

環境モデル
安全性評価項目
運用データ（事故・ヒヤリハット情報等)による評価項目策定
Copyright © 2022 METI/IPA

7

1-4 自律移動ロボットプログラムの主なスケジュール• ステークホルダと議論を積み重ねながら、プロトタイプ開発、中長期的な実証、社会実装まで見据えたアー
キテクチャ設計を進めていく。
• デジタル庁からのアーキテクチャの設計依頼に基づき、報告書を取り纏め、その後は社会実装に向けて、継続して検討を深めていく。（本プロジェクトは自律移動ロボットプログラムの一部）

2021年度

2023年度〜

2022年度
空間情報アーキテクチャプロジェクト第１期▲
2021年12月
プロジェクト発足▲
2022年５月
中間報告

アーキテクチャ設計

空間情報アーキテクチャプロジェクト第２期▲
2022年７月
報告書提出（本報告書）

社会実装

1 ビジョン実現に必要な機能を具体化

4 必要な環境整備に関する取組を具体化

2 協調領域と競争領域に機能を分類

5 各担い手が自らの役割を遂行

3 機能の担い手や関係性をデザイン

Copyright © 2022 METI / IPA

8

1-5 現状の課題認識
空間情報の管理と空間定義に関する統一的な基準、システム・データを繋ぐ汎用的な連携基盤が存在しないことが現状の課題と認識。
現状の課題（As is)•

空間情報が異なる仕様・規格で分散的に整備・管理されており、一元的な検索や収集・重ね合わせが困難
空間情報には、識別可能なメタ情報を有さず、流通を考慮した軽量化がされていな
いものが少なくない（機械やAIによる高速処理が困難）

空間情報の
管理基準

•

空間の
統一定義

•
•

空間を水平・鉛直方向で一意に定義する共通規格がない
業界によって異なる座標系や高さ基準を用いており、相互変換に用いる共通的な物
差しが必要

•

仕様の異なるシステム・データを相互に繋ぐ汎用的な連携基盤がないため、連携労力が大きく、データ提供者とアプリ開発者やユーザーが業界・地域横断で繋がらない

データ
連携基盤

結果として、貴重なデータやアプリケーション開発が一部のプラットフォーマーが提供する基盤に偏重している状態
Copyright © 2022 METI / IPA

9

1-6 本プロジェクトにおける検討事項
現状の課題を踏まえ、本プロジェクトでは以下①〜④のテーマを検討。なお、プロジェクト第１期では、
テーマ①〜③を中心に検討した。

•••

空間定義に関する共通規格の整備

データ連携基盤の構築①空間を一意に特定可能な規格③最適なシステムアーキテクチャの検討

高さ方向を含む3次元の空間定義
異なる分解能に対する要求への対応方法
地下、地上、空中に対して地域横断・シームレスな
適用可能性

•
•
•

④基盤システムの開発・利用普及②空間に情報を記述する統一的な規格•••

データの属性を簡易にメタデータとして空間に紐付け可
能な方法
静的な位置や属性情報に加え、時間の概念を有する
動的情報への対応機械による可読性

基盤システムに対する要求機能の抽出
要求機能に基づく、システム構成の検討
領域別基盤システムと、共通基盤システムの機能分担
検討

•
•
•

•

共通機能のモジュール化、OSS化等による基盤システムの開発促進方法
既存のシステムやデータフォーマットとの互換性確保による基盤システム利用の普及方法
インセンティブ・エンフォースメントや標準化、事業モデルを含めた普及方法
サーバー構成も含めた、効率的なデータ処理の在り方
Copyright © 2022 METI / IPA

10

２

本プロジェクトが目指すビジョン

2-1 ３次元空間情報基盤により実現するビジョン・世界
2-2 空間IDと3次元空間情報基盤の役割
2-3 ３次元空間情報基盤の整備の概要

11

2-1 ３次元空間情報基盤により実現するビジョン・世界
空間IDと、３次元空間情報基盤の実装・普及が、前述の課題解決を通じ、Society5.0が目指す世界の実現に寄与すると考える。
Society5.0において分野横断で目指す世界※
社会、消費者、事業者の課題解決と便益向上

企業の壁を越えた
エコシステム全体の成長

３次元空間情報基盤により実現する事項• ニーズを叶える提供価値を大きく増やしながら、フィジカルでのコストを劇的に減らす• 空間情報を機械が判読可能な形式で軽量かつ安価に提供することで、自律移動モビリティの安
全・効率的な運行を支援• 取引や提供機能の情報規格を統一するなどして各機能をモジュール化する• 協調領域は領域横断で機能をモジュール化・
OSS化し、アプリケーション・サービスの開発が簡易化される• インターネットのような仮想的な統合データス
最適なフィジカルの ペースで、フィジカル情報を共通の情報規格（ID・属性等）に統一
動きをサイバー上• データの入出力・参照を通じて実世界の取で実現
引や行為を制御するデジタルインフラの整備• データ流通を加速させるシームレスなデータ連携の共通基盤が構築され、既存のシステムや規格とも互換性と拡張性を有している• 様々な空間情報が空間IDを共通インデックスとして連携し、現実世界の様々なアプリケーションで活用されることによるバーチャルとフィジカルの融合が促進
Copyright © 2022 METI / IPA

12

2-2 空間IDと3次元空間情報基盤の役割
3次元空間上の一意の識別子データの相互連携・流通
アプリケーションの創出

バーチャルとフィジカルの融合の促進グローバル展開• 人・機械が認識可能な3次元グリッドを整備し、様々な地理空間情報やベースレジストリを仮想空間上に付与された一意の識別子（ID）と紐付け、相互に参照可能とする。

• 現状はドメイン別の固有ルールで管理されている静的・動的な情報を空間IDに紐付けることで、業界横断のデータ連携を促進。
• 一意の空間IDに紐付いた属性情報の登録・更新・検索を可能とすることで、空間情報のデジタル化やデータの流通、データを活用したアプリケーション創出を促進。
• 空間演算機能等、3次元空間情報基盤の機能により、空間情報を機械が判読可能な形式
で軽量かつ安価に提供することで、自律移動モビリティの安全で効率的な運行を支援。

• 整備・運用の仕組を標準モデルとしてグローバル展開することで、同基盤の上で活用されるシ
ステムや機械、設備等も併せて輸出できるようにする。これにより、日本が強みをもつ機械・インフラと通信が融合した次世代デジタル競争におけるイニシアティブの獲得を企図。
Copyright © 2022 METI / IPA

13

2-3 ３次元空間情報基盤の整備の概要
デジタル完結・自動化・全体最適化を実現し、自律移動ロボットの社会実装を進めるため、自律移動ロボット・システムが異なる種類の空間情報を簡易に統合・検索したり、軽量に高速処理できる仕組みとして、異なる基準に基づいた空間情報であっても一意に位置を特定できる3次元空間ID（点ではなく荒い区切りの箱状のグリッドで定義）を検索キー（インデック
ス）として導入し、鮮度の高い様々な空間情報（時間情報含む）を高速に自動的に結合できたり、簡単に検索できるようにする技術開発・標準化を行う必要がある。
建
物
情
報

空間ID

樹
木
情
報

空間ID

気
象
情
報

①統合・検索の作業が簡単に。

②ロボットやシステムが利用しやすい形に。
軽量化
高速処理

自動結合
ID検索

=飛行不可

空間ID

=飛行可

３次元空間情報基盤※様々な空間情報について、政府・民間が最新情報に更新するための頻繁な検索・統合は負担が大きい。
また、人間が読む前提の空間情報は、情報量が多く、ロボット、システムによる高速処理が難しい。

３次元空間情報利用
アプリケーション（例：ドローン運行管理）
Copyright © 2022 METI / IPA

14

3

ユースケースの検討
3-1 3次元空間情報の活用ユースケース
3-2 検証項目の基本的な考え方
3-3 ドローン運行管理
3-4 地図・GIS
3-5 地下埋設物管理15

3-1 3次元空間情報の活用ユースケース
・プロジェクト第１期では、ドローン運行管理、地図・GIS、地下埋設物管理 の3つの領域に絞り、サービサーへのヒアリングを通じてユースケースのコンセプトを深堀するとともに、東大井のサンプルデータを用いた検証を実施。
・地上モビリティでの安全確保や、海上での活用、屋内空間との連携その他ユースケースによる価値創出も想定されるが、これらユースケースは、プロジェクト第２期で検討予定。

産業
用途

エンターテインメント

交通・物流

都市環境計画・管理

警備・監視

生活支援

建築・土木

教育

災害対策

公共
用途

Copyright © 2022 METI / IPA

16

3-1参考 空間ボクセルによる空間情報の可視化検証
空間をボックス状に切り分けた「空間ボクセル」を定義し、各種の情報を簡易化して空間ボクセルに紐付けることで、複数種の情報を統合し、取扱いを容易にする。以下サンプルでは東大井エリアに空間ボクセルを作成し、属性情報を付与して可視化した。
建物データ（PLATEAU）との紐付け

気象データとの紐付けIDによる親子ボクセルの特定

親ボクセルID

GSI, Esri, HERE, Garmin, GeoTechnologies,
Inc., METI/NASA, USGS
GSI, Esri, HERE, Garmin, GeoTechnologies,
Inc., METI/NASA, USGS

5339352900_400

子ボクセルID

紐付けた風速の条件によるエリア抽出の実現性の確認

ボクセルに紐付けた建物情報の3次元表現を確認（風速 5m/s 以上のエリアの抽出）
複数の建物を含むボクセルへの紐付け方法の検討

533935290000_400
533935290000_450
533935290001_400
533935290001_450
533935290010_400
533935290010_450
533935290011_400
533935290011_450
Copyright © 2022 METI / IPA

17

3-2 検証項目の基本的な考え方
各ユースケースの性質に応じて「安全に、早く、安く」サービスを提供できるかを検証するためのKGIを設定する。また、ユース
ケース横断で共通して「多く、汎用的かつ簡単に」利用できるかを検証するためのKGIを設定する。さらに、その実現のための検証する項目を仮説として提示（P20,23,27参照）。今後、実証事業者と議論して、加除・具体化していく。

物流系ユースケースのKGI例

安全に運行できる。
インシデント数/運行距離

点検・工事系ユースケースのKGI例

共通のKGI例

安全に点検・工事できる。 データ流通量が多い。
インシデント数/点検・工事数

基盤との連携データ量
基盤からのデータ利用量

早く届けられる。
配送所要時間
※現在、注文から配送まで時間を要する
地域・区間を中心に効率化を検証

安く運行できる。
運行経路策定コスト
ロボット製造コスト

早く点検・工事できる。

様々なシステムに繋がる。

点検・工事所要時間

基盤と連携するシステム・サービス数※点検・工事の実施を決めてから現場で着手するまでの所要時間

安く点検・工事できる。
インフラ運用・管理コスト※ITシステムに限らず、ロボットやデータも含む。

簡単に扱える。
利用者の操作手順数
開発者の開発工数
Copyright © 2022 METI / IPA

18

3-2 ドローン運行管理： (1)ユースケース概要••

飛行計画作成にあたっては、地物等の空間占有情報と、気象/規制/電波/人流情報等のエア/グランドリスクの算出に必要な情報を、空間/時間に紐づいた状態で利用する。
運行管理(離着陸/飛行)時は、飛行計画時に入手した情報から変化がある場合に、即時的な情報共有が必要となる。
複数情報の空間への紐づけのイメージ
DID地区（グランドリスク評価を実施）

突発的な事象電波カバレッジ外エリア（エアリスク評価を実施）

空間IDの活用・期待効果
空間IDの活用• 鉄塔/建物等の３次元形状データ(CityGML等)を３次元空間の占有情報へ変換し、ドローン飛行計画作成に活用• 空間占有/気象/人流/電波等の様々な座標(2D,3D)系/フォーマット
の情報を、統一的な空間に紐づけることにより、飛行計画作成時の情報検索を効率化• 情報更新頻度の違いに応じた情報共有(Pullによる検索/Pushによる変化有の通知)方式による飛行計画時と飛行時での空間IDの活用

期待効果• 飛行計画作成時における、 ドローン運行者の情報入手を効率化• 各種情報のタイムリーな提供による、ドローンの安全で効率的な運行への貢献

飛行時には、静的な情報に加え、突発リスクに対応するためのリアルタイムな情報連携が必要

空間IDに紐付けられる情報に対する要求の整理や、標準的なガイドラインの整備が必要
Copyright © 2022 METI / IPA

19

3-3 ドローン運行管理： (2)将来ビジョンと社会実装ステップ
サービスの普及に向けた社会実装ステップ、2030年の将来ビジョン実現に必要な取組及び検証・評価項
目として以下が想定される。
将来ビジョン(2030年頃)

将来ビジョン
実現に必要な取組• 移動経路策定に必要な情報(3D
地理情報、飛行禁止地域、気象、電波等)の効率的な提供• 広域でのサービスの本格提供に向け、安全性・信頼性等の水準の向上空間ID・空間情報基盤（デジタルツイン）を活用して、都心部を含む全国で、ドローンが安全に大量・高頻度・高密度に飛び交い、点検、警備、物流等のサービスが提供される社会

現状

実装
第1
段階

実装
第2
段階

社会実装ステップ

検証項目の例[現状：空間ID実証前]• 現状のユースケースシナリオ
拠点間移動、インフラ点検等• 現状の事業主体・ステークホルダー
ドローン運行事業者、ドローン製造事業者、ドローンインフラ事業者、ドローンを活用したサービス利用者、行政機関

ー【2025年 空間ID実証後]• 実証シナリオ
地方都市郊外でのドローンを用いた点検、警備、物流等• 実証事業者・ステークホルダー
ドローン運行事業者、空間情報提供事業者、ドローン製造事業者、ドローンイ
ンフラ事業者、ドローンを活用したサービス利用者、保険会社、行政機関• 限定地域での本格運用時のKGI• 上記の場合の事業主体・ステークホルダーのシステム連携• 上記の場合の安全性・信頼性や知財・プライバシーの確保【2030年]• 想定される事業化シナリオ：
全国でのドローンを用いた点検、警備、物流等• 想定される事業者ステークホルダー
ドローン運行事業者、空間情報提供事業者、ドローン製造事業者、ドローン整備事業者、ドローンインフラ事業者、ドローンを活用したサービス利用者、保険会
社、行政機関• 広域での本格運用等のKGI• 上記の場合の事業主体・ステークホルダーのシステム連携• 上記の場合の安全性・信頼性や知財・プライバシーの確保

Copyright © 2022 METI / IPA

20

3-3 ドローン運行管理：(3)ドローンプロジェクトから空間情報への要求事項
レベル4での運行の際の空間情報への要求事項を仮説ベースで整理。ユースケースに応じて、要求水準は変わり得るので、今後、検討を深めていく必要がある。
情報更新頻度
情報種別

空間情報への要求

検討の方向性

数時間〜数日計画時からの変化を即時経路計画作成、障害物回避のために空間の占有情報が必要
グランドリスク判断の材料として地形(川、道路等)の情報が必要

・地物(鉄塔等)：PLATEAUを情報提供者とし、空間ボクセルに変換した利用を想定
・地形(川、道路等)を2Dの情報として利用
・地図整備事業者との連携が必要

数分〜数日

計画時からの変化を即時経路計画作成時には飛行日時の気象予報(降雨量、 ・気象情報を空間ボクセルに紐づけた状態での風速、気圧等)が必要
利用を想定
飛行時には突発的な気象(竜巻等)の情報が必要
・気象情報事業者との連携が必要

規制情報

数時間〜数日計画時からの変化を即時固定的に設定されている飛行禁止/制限空域(空港、重要施設等)の情報が必要
火災等により一時的に飛行を禁止する必要のある空域の情報が必要・国土交通省指定の禁止空域の情報を空間
ボクセルに紐づけた状態での利用を想定
・一時的飛行禁止空域の設定ついては規制当局との連携の仕組みが必要

電波情報
・通信カバレッジ
・衛星測位

数日

計画時からの変化を即時

衛星測位/電波不感地帯を避けて飛行計画を作成するために測位/通信カバレッジの情報が必要

・通信カバレッジを空間ボクセルに紐づけた状態
での利用を想定・通信キャリアとの連携が必要

人流情報

数時間〜数日計画時からの変化を即時

人口密集地帯を避けて飛行計画を作成したい。飛行時も、密集地を避けるために経路変更したい。

・2Dの統計情報としての利用を想定
・情報源については課題

計画作成
/検証時

離着陸
/飛行時

地物・地形情報

気象情報

Copyright © 2022 METI / IPA

21

3-4 地図・GIS： (1)ユースケース概要(屋内外のシームレスな人と自律移動モビリティの移動)
空間ID・ボクセルを活用し、様々な静的・動的データ及び運行管理システムと連携した汎用的なナビゲーションを検討。自律移動モビリティなど先進サービスの導入とデータ利活用の促進を見込む。
屋内空間のナビゲーション

空間IDの活用・期待効果
空間IDの活用• 地図データ、POI情報（建物入口等）等の静的情報や、人流・統計データなど動的情報を空間ID・ボクセルに紐付け、効率的・高度な経路検索とナビゲーションに活用• 基盤システム上で空間IDに紐付けられたデータ・メタデータはモビリティに限らず、人向けのナビゲーションなど多様な用途の利活用
を見込む

アプリ
ケーション

運行管理
システム

期待効果

3次元
空間情報
基盤
システム

データ
提供者

データ

地図
データ

POI
情報

メタデータ

バリア
情報

静的情報（例）

人流
データ

センサー
データ

統計
・時間
データ

動的情報（例）• 静的・動的なデータを連携させた屋内ナビゲーションの汎用手法として商業施設、オフィス、マンション等様々な施設での利用を見込む• 物流サービス事業者、フードデリバリ事業者等の利用により、自律移動モビリティを活用したサービスを促進

Copyright © 2022 METI / IPA

22

3-4 地図・GIS： (2)将来ビジョンと社会実装ステップ(屋内外のシームレスな人と自律移動モビリティの移動)サービスの普及に向けた社会実装ステップ、2030年の将来ビジョン実現に必要な取組、及び検証・評価項目として以下が想定される。
将来ビジョン(2030年頃)

将来ビジョン
実現に必要
な取組

•

空間IDを基準として、屋内地図及びPOI情報を共有・取得可能な簡易システムの構築• エリアマネジメント会
社等が自社で所有するBIMと空間ID
を連携

空間ID・空間情報基盤（デジタルツイン）を活用して、屋内外での空間情報のデータ流通や新たなアプリケーションの創出を促進して、屋内外でシームレスに自律移動モビリティや人が効率的に移動し、それに伴って業務の効率化が進んだ社会

現状

実装
第1
段階

実装
第2
段階

社会実装ステップ

検証項目の例[現状：空間ID前]• 現状のユースケースシナリオ
屋内実証においては、ロボット事業者が生成した自己位置認識用の屋
内地図を基に経路を設計し、モビリティ運行管理に活用• 現状の事業主体・ステークホルダー
ロボット事業者、建物管理会社、小売事業者

ー【2023年 空間ID実証後]• 実証シナリオ
2D LiDAR用地図や建物内POIを空間IDに紐付け、配送モビリティや、人を対象とした汎用的な屋内ルーティングを実施• 実証事業者・ステークホルダー
ロボット事業者、建物管理会社、小売事業者、（物流会社）• 屋内での配送時のKGI• 上記の場合の実証事業者・ステークホルダーのシステム連携• 上記の場合の安全性・信頼性や知財・プライバシーの確保【2025年 (大阪万博)]• 想定される事業化のシナリオ
空間IDを基準とした屋内外/施設間を跨いだ配送（空間座標の指定）の実現• 想定される事業主体・ステークホルダー
既存ステークホルダーに加え、物流会社等、屋外から屋内の指定場所への配送が必要なユーザーによるサービスの利用• 屋内外/施設間を跨いだ配送時のKGI• 上記の場合の事業主体・ステークホルダーのシステム連携• 上記の場合の安全性・信頼性や知財・プライバシーの確保

Copyright © 2022 METI / IPA

23

3-4 地図・GIS： (3)空間IDの活用（屋内における配送ロボット運行の例）
今年度実証では、建物内の協調データを空間IDに紐付け、配送モビリティを対象とした屋内ルーティングに活用。今後は屋内外のシームレスな移動により、データの利活用と全体の流通コストの低減を目指す。
協調データ整備
データ生成

ビル管理
会社

BIM情報

配送ロボット
事業者

フロアマップ生成

空間ID紐付け

サービス
発注

経路生成

配送

配送ロボへ
経路指示

配送

POI情報

受注・配
送依頼

テナント
空間IDと、屋内POI、
バリア情報を紐付け、基盤側で属性として保持

注文者
サーバー・
DB

受注

空間ID、
POI
紐付け表

ロボット事業者
サーバー

3次元空間
情報基盤

現在位置と配送先、空間IDに紐付いたPOI、
バリア情報等をもとに最適な経路を生成発注（テナント
アプリから）

テナント受注
システム

商品受け渡
し

ロボット事業者
サーバー
Copyright © 2022 METI / IPA

24

3-4 地図・GIS： (4)屋内外のシームレスな人と自律移動モビリティの移動における要求事項
空間IDを活用した配送ロボット運行管理と、人のナビゲーションにおいては協調データとして静的情報と、動的な空間情報の活用に伴い、基盤システム側の機能拡張とデータ仕様の整備が求められる。
配送ロボット運行・人ナビゲーションからの要求
情報種別

情報更新頻度
計画作成時

運行時

検討の方向性・課題等

空間情報の用途

移動センシング
データ

数分〜数時間-移動式モビリティによるセンシングデータの取得と、施設管理効率化（空調料金削減、CO2排出量削減、管理工数削減）への活用•

リアルタイムデータの保持・更新に関する基盤システム側のDBスキーマや空間情報の登録・紐付けに関する仕様の検討

人流・人の動態情報

数分〜数時間計画時からの変化
を即時

配送ロボット、人のARナビゲーションの経路設計、及び移動時のルート変更における人混み回避や、購買を促す為の行動変容に活用•

リアルタイムデータの保持・更新に関する基盤システム側のDBスキーマや空間情報の登録・紐付けに関する仕様の検討

建物内POI情報

月〜年-

配送ロボット、人のARナビゲーションの経路設計における進入不可エリアなどフロア内、エレベータ・階段など階層間移動時の参照•

共通仕様ライブラリによる空間IDへの変換・紐付けが可能なデータフォーマット整
備

BIM情報

変化なし

-

配送ロボット、人のARナビゲーションの経路設計においてBIMデータを協調データとして活用••

IFCなど汎用的なデータフォーマット
BIM情報の効率的変換 (OSS SW提供)Copyright © 2022 METI / IPA

25

3-5 地下埋設物管理：(1)ユースケース概要
地下埋設物が埋設されている地下空間を空間IDにより管理する。地下工事において、埋設物の照会漏れを防ぐとともに、掘削工事時の設備事故を防止及び掘削結果の記録を行うユースケースについて実証を行う。
埋設物照会・建機マシンガイダンス
アプリ
ケーショ
ン

埋設物照会

マシンガイダンス

設備
存在範囲

空間IDの活用・期待効果

掘削情報管理

設備
存在範囲

掘削後
地面情報

個別
システム

空間IDの活用• 地下埋設設備の詳細な位置など公開が難しい情報を、空間IDにより地下空間の利用状況としてインデックス化することで、埋設物事業者間のデータ還流を見込む• 基盤システム上で空間IDに紐付けられたデータ・メタデータは、埋設物事業者の埋設物照会での活用や、工事における設備事故防止など、今後様々な用途に活用が可能

期待効果
3次元
空間情
報基盤
システム
データ
提供者

データ

上水道

下水道

メタデータ

電力

静的情報

ガス

通信

• 埋設物照会の自動化など、地下工事における埋設物照会稼働の削減や、工事期間の短縮が期待できる• 建設機械のマシンガイダンス機能に地下空間の利用状況を含めることで、設備事故防止につながり安定的なインフラサービスの実
現に寄与する• 今後、設備災害対策などの利活用が見込まれる
Copyright © 2022 METI / IPA

26

3-5 地下埋設物管理：(2)将来ビジョンと社会実装ステップ
サービスの普及に向けた社会実装ステップ、2030年の将来ビジョンの実現に必要な取組、及び検証・評価
項目として以下が想定される。
将来ビジョン(2030年頃)

将来ビジョン
実現に必要な取組

既存サービスへ実証
成果を活用することに事業展開の拡大

運用手処理の標準化によるコスト削減と、災害復旧対応等の他活用分野への実証成果の活用

空間ID・空間情報基盤（デジタルツイン）を活用して、中核都市クラスの自治体で、地下埋設物情報が管理されて、施工管理の省力化や施工時の設備事故防止、さらには災害復旧対応をはじめとした様々な分野でのインフラの運用・管理等が効率化された社会
社会実装ステップ

検証項目の例

現状[現状：空間ID前]•現状のユースケースシナリオ
工事者が地下埋設物工事を行う際に、該当エリアに地下埋設物が存在するかを各事業者毎に事業所に行って確認している。
•現状の事業主体、ステークホルダー
地下埋設物事業者

ー

実装
第1
段階

【2023年 空間ID実証後]•実証シナリオ
埋設物照会サービスに、地下埋設物の3次元空間IDアーキテクチャを実装し、自社での業務に利用（自社DX推進）•実証事業者・ステークホルダー
地下埋設物事業者、自治体• 自社利用時のKGI• 上記の場合の実証事業者・ステークホルダーのシステム連携• 上記の場合の安全性・信頼性や知財・プライバシーの確保

実装
第2
段階

【2025年 (大阪万博)]•想定される事業化のシナリオ
3次元空間IDアーキテクチャを採用した地下埋設物照会サービスの大都市圏への拡大及び災害復旧対応等への応用サービスの実現•想定される事業主体・ステークホルダー
地下埋設物事業者、自治体• 広域運用時のKGI• 災害復旧等の他活用分野での利用時のKGI• 上記の場合の事業主体・ステークホルダーのシステム連携• 上記の場合の安全性・信頼性や知財・プライバシーの確保

Copyright © 2022 METI / IPA

27

3-5 地下埋設物管理：(3)空間IDの活用
今年度実証では、地下埋設物情報を空間IDに紐付け、埋設物照会・建設機械のマシンガイダンスに活用。
分散管理された地下埋設物情報を事業者間で相互参照可能とすることで、全体のコストの低減を目指す。
協調データ整備
データ生成

地下埋設
物事業者
地下工事
事業者
サーバー・
DB

サービス

空間ID紐付け

埋設物照会

建設機械マシンガイダンス

地下埋設物情報
空間IDと、地下埋設物情報の形状を3次元化し紐付け、基盤側で属性として保持

3次元空間
情報基盤

工事範囲
における埋
設物照会

工事範囲
における埋
設物有無

埋設物照会
システム

施工
計画

掘削範囲に
おける埋設
物照会

照会結果を
マシンガイダンスに設定

掘削範囲における埋設物の有無を、マシン
ガイダンスに登録し、建設機械オペレータに視認しやすいUIにより注意喚起を行う

建設機械
管理システム

工事範囲を空間ID化
し、そのエリアにおいて地下埋設物の有無を紐付けることにより、工事範囲における埋設物の有無を返却する

掘削工事

掘削範囲を空間ID化
し、そのエリアにおいて地下埋設物の有無を紐付けることにより掘削範
囲における埋設物の有無を返却する
Copyright © 2022 METI / IPA

28

3-5 地下埋設物管理： (4)地下埋設固有の課題
地下埋設物事業者により地下埋設物の位置基準や管理方式が異なるため、事業者間の相互活用が困難となっている。
地下埋設物情報の管理パターンに応じたデータ共通化（共通の３次元座標への位置合わせ方法を含む）の手法について検討を行い、今後の実証を通じて効率的な運用手法を確立していく。

パターン１
図面管理
図面で管理
されている
地下埋設設備パターン２
独自管理
独自システムで管理されている
地下埋設設備パターン３
GIS管理
Shapeファイルで管理されている
地下埋設設備図面
ラスタデータ（平面図/縦断図等）

運用の課題抽出※1

図面ラスタデータから、空間IDの生成に必要なデータのみを抽出し、位置基準をベースに座標の付与を行い、空間ID変
換用のShapeファイルに変換を行う。

ラスタ/ベクタ変換※1※2

独自形式のGISデータから、空間IDの生成に必要なデータのみを抽出し、位置基準をベースに座標の付与を行い、空間ID変換用のShapeファイルに変換を行う。

※3

標準GISデータ（Shapeファイルを想定）から、空間IDの生成に必要なデータのみを抽出し、位置の整合性を確認し、
空間ID変換用のShapeファイルに変換を行う。

独自管理
データ

独自形式
変換※2

GISデータ

空間ID変換用
フォーマット変換※3（Shapeファイル等）

空間ID変換用
Shapeファイル

共通仕様
ライブラリ

空間ID

空間ID
レベルによる
データ提供の容易性

Copyright © 2022 METI / IPA

29

3-5 地下埋設物管理：(5)地下埋設物情報への要求事項
地下埋設物情報において、本ユースケースで必要となる要求事項は以下の通り。情報更新は定期的に実施される必要があり、空間情報から空間IDへの紐付けについては、将来的に事業者自らが実施できることが望ましい。

埋設物照会における要求
建設機械マシンガイダンスにおける要求
情報種別

情報更新頻度検討の方向性・課題等

空間情報への要求

電力

定期更新（月〜年）
データ提供時点の最新情報

電力設備の地下における占用情報が必要
設備形状が推定可能な情報が必要

・電力事業者を情報提供者とし、設備形状を3次元で構築した上で、地下における占用情報に変換した利用を想定
・将来的には事業者でデータ整備が可能な手法を検討

ガス

定期更新（月〜年）
データ提供時点の最新情報

ガス設備の地下における占用情報が必要
設備形状が推定可能な情報が必要

・ガス事業者を情報提供者とし、設備形状を3次元で構築した上で、地下における占用情報に変換した利用を想定
・将来的には事業者でデータ整備が可能な手法を検討

上下水道

定期更新（月〜年）
データ提供時点の最新情報

上下水道設備の地下における占用情報が必要
設備形状が推定可能な情報が必要

・自治体を情報提供者とし、設備形状を3次元で構築した上で、地下における占用情報に変換した利用を想定
・将来的には自治体でデータ整備が可能な手法を検討

通信

定期更新（月〜年）
データ提供時点の最新情報

通信設備の地下における占用情報が必要
設備形状が推定可能な情報が必要

・通信事業者を情報提供者とし、設備形状を3次元で構築した上で、地下における占用情報に変換した利用を想定
・将来的には事業者でデータ整備が可能な手法を検討する
Copyright © 2022 METI / IPA

30

4

空間の定義
4-1 空間ボクセルの構造に関する意見集約
4-2 空間IDによる空間の分割方法検討の方針
4-3 空間ボクセルを配置する高さの基準面
4-4 空間の分割方式
4-5 IDの形式
4-6 その他空間定義における要検討事項

31

4-1 空間ボクセルの構造に関する意見集約
サービサーや実証実験対象分野（ドローン、地下埋設物、GIS）から空間ボクセルに関する意見を集約。
【コンセプト】

空間ボクセル（イメージ）• 3次元空間を空間ボクセルによって分割し、一意のID（空間ID）によって識別する仕組みを実現することが望ましい• 空間ボクセルに地物/事象を紐付け、その空間に何が存在するかを把握するインデックスとして使用する仕組みが望ましい【重視する点】• 標準化/国外/多様なユースケースへの展開を視野に入れ、開発者が使いやすく普及しやすい構造が望ましい⇒ 国内外においてすでに実績のあるグリッドシステムをベースにする
モートンオーダーの例【開発/実装の観点におけるサービサーからのフィードバック】

出典:https://en.wikipedia.org/wiki/Geohash• CPU演算処理との親和性を鑑み、モートンオーダー等、隣接する空間ＩＤを少ない演算で算出可能な仕組みが望ましい• 3次元方向への実装の技術的な難易度を考慮し、空間ボクセルの形状は立方体を基本として、実証を通じて評価すべき• 空間ボクセルの生成やIDの付与において既存のアルゴリズム/ライブラリが活用可能な仕組みが望ましい【実証実験対象（ドローン、地下埋設物、GIS）分野での空間ボクセルに関するヒアリング】
検討項目

フィードバック

セルの形状

現在想定する用途では四角形の形状であれば課題はない

高さの基準

ボクセルの標高値などが取得可能であれば課題はない

体積の均一性

緯度経度による分割によって地域ごとにボクセルの体積が異なっても、情報のインデックスの用途としては課題はない

水平方向の分解能

現在の最小は地下埋設ユースケースにおける 0.5～1m 四方のグリッド

高さ方向の分解能

最小単位で 50cm 程度が主要な要件になると考えられる
Copyright © 2022 METI / IPA

32

4-2 空間IDによる空間の分割方法検討の方針
空間分割の基本要素（①ボクセルを配置する高さの基準面、②空間の分割方式（水平方向/鉛直方向）、③IDの形式）について方向性を示し、実証から得られるフィードバックによってその妥当性を確認する。

② 4-4 空間の分割方式（水平方向/鉛直方向）① 4-3 ボクセルを配置する高さの基準面

ID = ##ABC③ 4-5 IDの形式

Copyright © 2022 METI / IPA

33

4-3 (1) 空間ボクセルを配置する高さの基準面
公共測量成果など一般に整備され流通している空間データの高さ基準が標高であることを考慮し、空間ボクセルを配置する
基準面にはジオイド面を採用。各ユースケースで実施予定の実証結果を踏まえ、その妥当性を確認する。
ジオイド面を基準面とした空間ボクセルの配置イメージ【ジオイド面に空間ボクセルを配置】• ジオイド面を標高 0m の平らな基準面とした座標空間上において、基準面上に空間ボクセルを配置する• 標高を基準に整備された空間データを直感的に空間ボクセルに紐付けることができる• 重力方向のベクトル（人が認識する高さ方向）により近い表現で空間ボクセルを配置することができる

Esri, Intermap, NASA, NGA, USGS | GSI, Esri, HERE,
Garmin, GeoTechnologies, Inc., METI/NASA, USGS

論点

ジオイド面

楕円体面

空間IDとの紐付け

空間ボクセルの高さは標高となり、多くの空間データが持つ高さ情報（標高）をそのまま紐付けることができる

空間ボクセルの高さは楕円体高となり、多くの空間データが持つ高さ情報（標高）を変換して紐付けを行う必要がある

空間ボクセルの鉛直方向

重力方向のベクトル（人が認識する高さ方向）により近い表現で配置される楕円体面から鉛直方向に積み上げられるため、重力方向のベクトルとは一致しない方向に配置される【ジオイド面を基準面とした場合の検討事項】

日本のジオイド2011• 空間データを空間IDに紐付ける際に基準となるジオイドモデルを空間IDの仕様として定義すべきか• 基準となるジオイド・モデルを定めるべきか（GISソフトウェアなどではEGM96等が良く用いられているが国内においてはより正確な日本のジオイド2011が存在する）• システムごとに異なるジオイドモデルを採用した場合、IDの互換性を保つためには補正を行う必要がある

出典:
https://www.gsi.go.jp/buturisokuchi/grageo_geoidseika.html

Copyright © 2022 METI / IPA

34

4-3 (2)空間ボクセルを配置する高さ基準面の方針案
ジオイドモデルは地域によって使い分けられているため、地域に応じた高さ基準をメタデータとして明示できるようにする。日本においては日本のジオイド2011（東京湾平均海面を0mとするもの）が標準的な高さの基準面となる。（離島（無人島）や海域で高さを扱う場合においては、状況に応じた高さの基準が用いられている）
ジオイドモデルについて
衛星測位から高さを求めるためのデータとして「ジオイドモデル」がある。統一的な地球規模のジオイドモデルは空間分解能が低く、地域によって精度に幅があるため、現在は用途に応じて複数のジオイドが使い分けられているが、基準面の違いを除き、ジオイドの選択に裁量のあるユースケースはほとんど存在しない。
【参考】ジオイドモデルの比較
日本のジオイド2011（国土地理院）

評価項目

評価

内容

EGM96

EGM2008（アメリカ国家地理空間情報局：NGA）（アメリカ国家地理空間情報局：NGA）

評価

評価

・重力計測＋水準/GNSS測量

内容
・重力計測

内容
・重力計測

整備方法及び分解能〇

・分解能
緯度1分×経度1.5分(約2km)

×・分解能
緯度15分×経度15分(約30km)△

・分解能
緯度2.5分×経度2.5分(約5km)

適用範囲

△

日本

〇

全球

〇

全球

用途

〇

日本の地理空間情報整備

×

学術研究

×

学術研究

※ EGM2008の後継として、EGM2020が整備中
Copyright © 2022 METI / IPA

35

4-4 (1) 空間の分割方式：水平方向の分割方式の候補
既存の2次元のグリッドシステムをベースとして空間を分割することを検討。
以下の比較項目における評価を踏まえて、XYZタイル（有力候補）とGeohashについて比較検討した。
出典:https://www.esrij.com/gisguide/coordinate-andspatial/coordinate-system/

出典:
https://maps.gsi.go.j
p/development/siyou.html

投影平面の分割
比較項目
分割方法
CPU演算に親和性の高い
階層的な分割方法か

セルの形状正方形に近い形状か

オープン性
仕様やライブラリが広く公開されているか

対象範囲
全球を重複のないセルでカバーしているか

国際的な認知度
国内外における事例
商用S/W等への採用実績

XYZタイル出典:
https://docs.ogc.org/
as/20-040r3/20040r3.html

緯度経度による分割
MGRS

Geohash

投影立方体の分割

標準地域メッシュrHEALPix（DGGS）

GeoSOT-3D

〇

×

〇

×

△

〇

4分割を
繰り返す

レベルにより分割方法が異なる

32分割を
繰り返す

レベルにより分割方法が異なる

各立方体面の9分割を繰り返す

立方体の8分割を
繰り返す

〇

〇

△

〇

〇

〇

正方形に近い形状

正方形に近い形状

長方形

正方形に近い形状

正方形に近い形状

立方体に近い形状

〇

〇

〇

〇

△

△

Web地図の標準手法として認知されている

世界標準として認知されているパブリックドメインの仕様

仕様はJIS規格化
されている

利用可能な
ライブラリ等が少ない

利用可能なライブラリ等が少ない

△

×

〇

△

〇

〇

極域の地域を除く（※1）

重複するセルが存在する

全球を対象

日本周辺を対象（※2）

全球を対象

全球を対象

〇

〇

〇

△

△

△

Web地図の標準手法として広く実装されている防衛分野等で活用
GIS製品等にも実装

GIS・DBMS製品等に広く実装されている

国内では統計データ等に広く活用されている事例や機能として実装しているS/Wは少ない

事例や機能として実装しているS/Wは少ない※1：北緯及び南緯約85.0511度以上を除く※2：全世界に対象領域を拡張した世界メッシュが存在する

Copyright © 2022 METI / IPA

36

4-4 (2) 空間の分割方式：水平方向・鉛直方向の分割案
ユースケースヒアリング結果によって得られた「鉛直方向の最小の分解能 50cm」を基準にXYZタイルと*鉛直方向は今後の実証等を踏まえて最適化
Geohashの想定されるボクセルサイズの比較は以下の通り。
XYZタイル

Geohash（精度レベル26 において高さ方向を50cmとした場合）（精度レベル 10 において高さ方向を50cm とした場合）

精度

緯度/南北方向（単位: m ）※経度/東西方向（単位: m ）※

鉛直方向（単位: m )精度

緯度/南北方向（単位: m ）※経度/東西方向（単位: m ）※

鉛直方向（単位: m )0

40,075,016.6784(約40,075km)

40,075,016.6784(約40,075km)

33,554,432(約33,554km)

1

4,989,600.00(約4,989km)

4,050,000.00(約4,050km)

256

1

20,037,508.3392(約20,037km)

20,037,508.3392(約20,037km)

16,777,216(約16,777km)

2

623,700.00(約623km)

1,012,500.00(約1012km)

128

・

・・・

・・・

・・・

3

155,925.00（約155km）

126,562.50(約126km)64151222.991222.991024

4

19,490.62（約19km）

31,640.62（約31km）

32

16

611.50611.50512

54,872.66

3,955.0816

17

305.75305.75256

6609.08988.77

8

・・・

・・・

・・・

・・・

7

152.27

123.6

4

24

2.39

2.39

2

8

19.03

30.9

2

25

1.19

1.19

1

9

4.76

3.86

1

26

0.60

0.60

0.5

10

0.59

0.97

0.5

※Webメルカトル座標上の距離でありXYZタイルのセルが存在する場所によって異なる※概算であり実際のサイズはGeohashのセルが存在する場所によって異なる
Copyright © 2022 METI / IPA37

4-4 (3) 空間の分割方式：ボクセルサイズの比較
地下埋設物の存在領域を最小サイズレベルとその1つ上位レベルの空間ボクセルで表現して、XYZタイルとGeohashを比較。
比較結果：Geohashのレベルによっては埋設物の特定に支障が出る可能性がある。
XYZタイル

Geohash※水平方向のボクセルサイズは概算のサイズで均一に作成

Geohashは、レベル間の水
平面の面積の差が大きいため、目的に合ったサイズのボクセルを設定できない可能性がある。
（レベル9の場合、道路によっては道路幅全体を覆うことになり、埋設物を特定しづらい、
など）

レベル25
(上下水道)
東西方向：1.0m
南北方向：1.0m
鉛直方向：1.0m

レベル26(電力・ガス・通信)
東西方向：0.5m
南北方向：0.5m
鉛直方向：0.5m

レベル25とレベル26の水平面の面積比⇒ 4:1

レベル9(上下水道)
東西方向：4.0m
南北方向：4.8m
鉛直方向：1.0m

レベル10(電力・ガス・通信)
東西方向：1.0m
南北方向：0.6m
鉛直方向：0.5m

レベル9とレベル10の水平面の面積比⇒ 32:1

Copyright © 2022 METI / IPA

38

4-4 (4) 空間の分割方式：埋設物管理トライアル（XYZタイル）
地下埋設物の存在領域及び埋設物数をXYZタイルベースの空間ボクセルで表現。
ユーザー候補から実用に耐えられそうとの評価が得られた。
地下埋設物サンプルデータとXYZタイルベースのボクセルのサイズ

元データの精度に応じた適切なボクセルサイズを設定可能
Copyright © 2022 METI / IPA

39

4-4 (5) 空間の分割方式：XYZタイルとGeohashの評価のまとめ
以下の比較評価結果、トライアルによる検証及びユーザーの声を踏まえ、XYZタイルを有力候補として実証等を進める。なお、
ユースケースの実証結果から得られるフィードバックを踏まえ、その妥当性を確認し、必要に応じて仕様を見直す。

評価項目

XYZタイル（ZFXY方式）
評価

コメント

〇

地理院地図のデータが配信されるタイルと同じ方式でデータの紐付けを行うことができる。

△

地理院タイルのサイズで分割されたデータをGeohashのボクセルに紐付けるにはデータの分割/統合などの変換処理が必要となる。

Web地図サービス/
地図アプリとの親和性〇

地図データの配信方式として多くのWeb地図サービス、
地図アプリケーションにおいてデファクトスタンダードとなっており開発者にも理解を得られやすい。

△

場所の特定等においては活用されているが、データを共有する方式としては標準的な方法ではない。

ボクセルの形状〇

水平面の形状が正方形であり、精度レベルによって縦横比が変化せず、精度レベルによってボクセル表現が大きく変化しない。

△

水平面の形状が長方形であり、精度レベルによって縦横比が変化するため、精度レベルによってボクセル表
現が変化する。

〇

精度レベル数は27個であり、データや用途に応じて柔軟にボクセルサイズを設定できる。

△

精度レベル数は10個であり、データや用途によっては
適切なボクセルサイズを設定できない可能性がある。

演算処理の高速化〇

モートンオーダーを採用した空間分割とID付与に対応〇

モートンオーダーを採用した空間分割とID付与に対応

鉛直方向を含めた
ID算出方式の実現性〇

鉛直方向も含めたIDの算出ロジックの案が存在する。

△

Geohashに高さ情報を付与したID算出のロジックを検討/考案する必要がある。

対象範囲

△

南緯約85度〜北緯約85度の範囲〇

全地球

地理院地図との親和性

精度レベルの数※最小のボクセルサイズを50cm程度のサイズとした場合

評価

コメント

GeohashCopyright © 2022 METI / IPA

40

4-4 (6) 空間の分割方式：水平方向の分割のベースとなる測地系現用されている測地系の圧倒的多数はITRF座標系に整合しており、正確な理解に基づく測地系の選択によって実態的な相違が生じるユースケースはほとんど存在しないため、 「JGD2011」と「WGS84」 いずれの適用も可とする。
測地系に関する方針案• 必要に応じて、適用範囲に応じて選択された測地系を、空間IDに準拠したデータセットのメタデータとして明示できるようにする。
• 第4期「地理空間情報活用推進基本計画」のシンボルプロジェクト「高精度測位時代に不可欠な位置情報の共通基盤『国家座標』の推進 」（国土地理院）と引き続き連携し、測地系に関する正確な理解を広める啓発に適宜協力する。

【参考】XYZタイルを採用している主なWeb地図が準拠している測地系
WGS84
OpenStreetMap
Google Maps
MapboxArcGIS Online

JGD2011(ITRF座標系GRS80楕円体)
地理院タイルOpenStreetMap
Google Maps
MapboxArcGIS Online「日本の測地系」（国土地理院）https://www.gsi.go.jp/sokuchikijun/datum-main.html#p3

Copyright © 2022 METI / IPA

41

4-4 (7) 空間ボクセルの形状に関する論点
論点：ドローン等のエアモビリティでは、水平移動が垂直移動より速く、高さ方向をより細分したいニーズあり。
① 垂直粒度と水平粒度を個々に指定できないか② もしくは、扁平な空間ボクセルを定義できないか
課題認識
・ドローンは水平方向の移動が中心
・気象データ等は比較的大きなメッシュサイ
ズで提供
・例えば150mメッシュの気象データの場合、飛行可能高度は150mのため、立方体形
状の場合は1ボクセルとなる(平面と変わらない）
垂直粒度と水平粒度はセット
精度

緯度

経度

高さ

検討状況
①垂直粒度と水平粒度を個々に指定
多様な形状のボクセルを定義可能とした場合、組み合わせが膨大になるため、データの互換・交換が行いにくい②扁平な空間ボクセルを定義
移動体の速度にも依存しユースケース毎に異なる可能性が高いため、現時点では適切な扁平率が不明①垂直粒度と水平粒度を個々に指定
精度

0

0

1

1

緯度

経度

精度

×

1

・

・

・

26

26

立方体近似

属性の利用によるグルーピング②扁平な空間ボクセルを定義
？m

150m
150m

150m

150m

・正立方体近似のボクセル形状として仕様検討を進め、今後の実証等を通じて問題がある場合は見直す・扁平ボクセルは、より粒度の細かいボクセルの集合として取り扱うことも可能であるため、機能としてボクセル集合を扱う処理方式を検討する組み合わせが膨大→データ交換に課題

026立方体近似のボクセル

高さ

当面の方向性150m

適切な扁平率→ユースケースごとに異
なる

精度

緯度

経度

高さ

0
1
・
26

Copyright © 2022 METI / IPA

42

4-5 IDの形式：ZFXY（案）XYZタイルの水平方向のインデックス（ID）計算式に鉛直方向のインデックス（ID）の計算を拡張する
ZFXY方式を検討（国土地理院/株式会社 Geolonia提供）。
鉛直方向を含めたIDを計算式により算出することが可能【インデックス（ID）計算式】
Web地図のデファクトスタンダードであるXYZ タイルの
タイル番号を計算する式をそのまま活用

x = floor(n * ((lng + 180) / 360))
y = floor(n * (1 - log(tan(lat) + (1 / cos(lat))) / PI) / 2)f = floor(n * h / H)
※ h = 標高 [m], n = 2^z, H = 2^25[m]【算出されるインデックス（ID）の形式】{z}/{f}/{x}/{y}例：16/13/57555/26008※z: ズームレベル、f: 鉛直方向インデックス、x: 東西方向インデックス、y: 南北方向インデックス
出典: https://unvt.github.io/zfxy-ruby/

出典: 国土地理院※ XYZタイルに関する知財の存在は確認できていないが、今後詳細な調査を予定
Copyright © 2022 METI / IPA

43

4-6 その他空間定義における要検討事項（１）空間IDへの地物/事象の紐付け方法
a.地物/事象の情報をどのように紐付けるか① データを紐付ける空間IDの精度レベルの選択② 地物/事象と空間IDの紐付けパターン③ 空間IDの紐付けを行うテーブル構造④ 複数の地物/事象と空間IDの紐付け

b.高さを持たない情報（人口統計等）をどのように空間IDに紐付けるか
c.動的な地物/事象の情報をどのように管理するか（２）時間情報の取り扱い

Copyright © 2022 METI / IPA44

4-6(1)a① データを紐付ける空間IDの精度レベル 検討例
地物/事象のデータは、そのデータの精度の基準となるレベルの空間IDに対して紐付けを行う方法、及び空間IDに紐付けた値を集約した集計データ（オプション）を作成することを検討。

上位ボクセルデータ

集計データの作成（オプション）

地物/事象データ

データの紐付け精度の基準となる
ボクセルデータ• 集計の方法（合計、平均、最大値、最小値等）は集計を行うデータの特性によって任意に変更することを想定• 集計データは複数の上位レベルの空間IDに再帰的に集計を繰り返して作成されるパターンも検討（画像データのピラミッドのような用途）• 解析などの用途でボクセルのサイズを一致させるために下位のレベルのボクセルに紐付けたデータを付与するパターンも想定

Copyright © 2022 METI / IPA45

4-6(1)a② 地物/事象と空間IDの紐付けパターン 検討例
多対多の紐付け構造で地物/事象と空間IDの組み合わせパターンを網羅することを検討。

空間ボクセル：地物/事象

1：1

1：n

n：1

n：m

例

空間ボクセルごとに集計された
統計メッシュデータ

IOTセンサー情報の
ポイントデータ

河川のラインデータ

建物のポリゴンデータ

地物/事象への空間IDの付与方法

地物/事象のレコードに空間IDを付与可能

地物/事象のレコードに空間IDを付与可能空間IDと地物/事象の管理IDのリンクテーブルが必要

空間IDと地物/事象の管理IDのリンクテーブルが必要

空間IDに地物/事象の属性を紐付ける方法

地物/事象の属性データを紐付け可能

地物/事象の属性データを集計する必要がある

地物/事象の属性データを紐付け可能

地物/事象の属性データを集計する必要がある

Copyright © 2022 METI / IPA

46

4-6(1)a③ 空間IDの紐付けを行うテーブル構造 検討例
空間IDに地物/事象データを紐付けをした際のテーブル構造を検討。

例: 建物データ

空間ID

建物ID

1234

111

1234

222

1235

222

空間ID–地物/事象リンクテーブル

(n:1)

111

222

1234

建物ID

名称

建築年

***

地物/事象テーブル（ソースデータ）※元データとして別システムに格納されるケースもあり

111

〇〇ビル

1963

***

222

△△町タワー

2009

***

空間ID

個数

1234

2

650

1235

1

1500

1235
空間ID

※実際のテーブル構造は各ユース
ケースのシステム毎に異なると想定<面積>_合計 <面積>_平均<面積>_最小<面積>_最大

325

250

400

1500

1500

1500

空間ID統計テーブル（オプション）*集計項目は任意

Copyright © 2022 METI / IPA47

4-6(1)a④ 複数の地物/事象と空間IDの紐付け 検討例
下記は領域別基盤システムのDB内の構造をイメージ。実際のテーブル構造は各ユースケースのシステム毎に異なると想定。
空間ID DB
メタデータテーブル

リンクテーブル（建物）統計テーブル（建物）建物テーブル（ソース）

リンクテーブル（鉄塔）統計テーブル（鉄塔）リンクテーブル（気象）統計テーブル（気象）

鉄塔テーブル（ソース）• 地物/事象テーブル（ソースデータ）が更新された場合はリンクテーブル、統計テーブルも自動更新される仕組みの検討が必要（動的データなど更新頻度が高いデータについては別のデータ構造が必要となる可能性も想定）• 地物/事象テーブル（ソースデータ）を外部システムに持つ場合は、外部システムのAPIに対応する必要あり（汎用的な仕組みではなく、対応するAPIごとに開発が必要となる可能性あり）

API
外部システム気象テーブル（ソース）

Copyright © 2022 METI / IPA

48

4-6(1)b 高さ情報を持たないデータの紐付け 検討例
高さ情報を持たないデータは、XYZタイル方式での運用を行うことで既存流通データとの互換性を確保する。
空間情報検索の際には、高さ情報を「持つ」データと「持たない」データを一度に指定可能な方法を考慮する必要がある。
高さ情報を持たないデータとの相互運用
・高さ情報を持たない2Dデータ（人口統計、用途地域、土地利用など）は2D用のID体系であるXYZタイル方式で取り扱えば相互運用が容易。
XYZの形式{z}/{x}/{y}z: ズームレベル
x: 東西方向インデックス
y: 南北方向インデックス

XYZタイルで提供された2Dデータ{z}{x}{y}タイル番号15/29098/12921

データ受領時にZFXYに自動変換{z}{Nil}{x}{y}高さ情報の固定値を自動付与(例)15/Nil/29098/12921

高さ情報の有無混在した空間IDの検索・検索用としては、高さ情報のあるデータ、無いデータを一度に指定する用途を考慮し、空間ID（ZFXY方式）の
鉛直方向インデックス(f) に特定の固定値を付与する方式を今後検討する。
ZFXYの形式{z}/{f}/{x}/{y}z: ズームレベル
f: 鉛直方向インデックス
x: 東西方向インデックス
y: 南北方向インデックス

空間IDを2D変換して提供も可能

高さ情報を持つデータに紐付けられる空間IDの例
15/1/29098/12921

高さ情報を持つものと持たないものの一度に指定する例

15/1 or Nil/29098/12921
Nil:高さ情報を持たばい場合の固定値（具体的な固定値は今後検討）
Copyright © 2022 METI / IPA49

4-6(1)c 動態情報の取り扱い方法の検討
動態情報（ドローンの機位など）を空間ボクセルで管理する必要性や共有する仕組みを今後検討する。

ドローンに関する動態情報共有の現状
ドローンの動態情報は、リモートID（ブロードキャスト、ネットワーク、LPWA）での共有、また、有人機からドローンへの動態情報の共有は、ADS-B（放送型自動従属監視）の技術を用いて、*NEDO DRESS Projectで実現されている。
*DRESS Project(NEDO ロボット・ドローンが活躍する省エネルギー社会の実現プロジェクト)https://nedo-dress.jp/

今後の検討

出典: https://mavicmaniacs.com/ads-b-for-drones

動態情報を空間ボクセルで管理して、他のデータと統合する必要性のあるケースがあるか？個別に共有する仕組みとするか？については、
領域別に検討する必要がある。

データ項目ごとに、入力方法・更新頻度・要求性能・妥当な共有方式が異なるものの、空間情報として取り扱うことのできる共通の方式は今後検討する。

Copyright © 2022 METI / IPA50

4-6(2) 時間情報の扱い方 検討例
地物/事象データが持つ時間に関する情報を空間IDに関連付けて、空間IDと時間を用いた管理や検索ができるようにする。
時間情報の種類【瞬間的情報】 発生時刻、予測時刻などを 「対象時刻」 列で保持（例：気象情報）【期間的情報】 実在期間、計画期間などを 「開始時刻」 と 「終了時刻」 列で保持（例：道路工事情報）

時間情報のメタデータ管理
時間情報を持つデータセットがある場合は、メタデータ項目「データの範囲（時間要素）」に対象時刻・期間を記載

時間情報の管理と検索の例
想定例）自治体（道路管理部署）の道路工事情報管理
工事ID：10
開始時刻：2022/7/10
終了時刻：2022/7/11

空間ID

工事ID

開始時刻 (JST)

終了時刻 (JST)1A

102022/7/10

2022/7/11

3A

20

2022/7/11

2022/7/13

3B

20

2022/7/11

2022/7/13

3B

30

2022/7/13

2022/7/15

3C

30

2022/7/13

2022/7/15

工事ID：20
開始時刻：2022/7/11
終了時刻：2022/7/13

A

B
C
1

2

3

工事ID：30
開始時刻：2022/7/13
終了時刻：2022/7/15

想定例）事業者の工事計画における地域全体の道路工事計画検索
Q. 7/12-7/14 に工事を行う空間ボクセルは?

空間ボクセル–道路工事リンクテーブル(地物/事象データの時間情報をリンクテーブルに付加)

道路工事区間データ（期間的情報）※ 時間要素をID化した構造については、今後検討する。

3A
3B
3C

Q. 7月に空間ID 「3B」 で行われる工事は？
空間ID

工事ID

開始時刻 (JST) 終了時刻 (JST)3B

202022/7/11

2022/7/13

3B

30

2022/7/13

2022/7/15

Copyright © 2022 METI / IPA51

5

3次元空間情報基盤のアーキテクチャ検討
5-1 アーキテクチャ：普及に向けたコンセプト
5-2 協調領域として整備する機能（案）5-3 共通ライブラリ
5-4 共通インタフェース
5-5 基盤システム構成（例）
5-6 メタデータ定義
5-7 空間ボクセルデータ定義
5-8 空間情報の検索方法

52

5-1 アーキテクチャ：普及に向けたコンセプト
空間ID・3次元空間情報基盤の活用・普及を促す要素として、分散型、既存システムとの互換性と、拡張性を重視した
アーキテクチャとする。また、各領域別基盤システムにおけるデータ・メタデータの保持方法は、共通基盤システムから領域横断で検索・アクセス可能な仕様とする。
空間IDを共通キーとして繋がる分散型システム
領域別基盤
システム
GIS
用システム

データカタログ

既存システムデータ

既存システム既存システム

データ
データ

既存システムデータ…

既存システム既存システム

データ
データ

既存システム

データ…

…

メタデータ情報から直接データにアクセスも可能

地上走行
モビリティ用
システム

データ
データ

…

メタデータの情報

既存システム既存システム…

条件検索

ドローン運行管理
用システム

データ

…

システムカタログ

既存システム

…

共通基盤
システム

データ
データ
…

地下埋設物管理用システム

既存システム既存システム…

領域別のシステム情報と、メタデータの情報を共通基盤
システムに登録

分散型システム

データの属性を
メタデータとして
空間IDに紐付け• 空間IDに紐付けられたデータの属性情報は、ドメイン別に管理・共有される分散型システム• 空間IDを共通キーとしたドメイン間の情報連携を可能とする

既存システムとの互換性• 汎用的GISアプリケーション、データフォーマットとの高い互換性（公開ライブラリにより、既存データの紐付けが可能）• ID体系は、人・機械が認識でき、データ間連携が容易な構造

拡張性• ID体系は一定の共通ルールのもと、カスタマイズ・拡張が可能(例：地物や図面等ドメイン特有情報をIDをキーに呼び出し)• 当初のシステム機能は3次元グリッドと階層構造のID提供、基盤情報の保持等に限定し、ニーズに応じて機能拡張が可能
Copyright © 2022 METI / IPA53

5-2 協調領域として整備する機能（案）
協調領域として、空間ＩＤルール、共通ソフトウェアライブラリの設計・整備、及び機能拡張のための仕様作成を協調領域として段階的に整備する。尚、データ統合、物理基盤等は競争領域として領域別基盤を個別かつ自由に活用・構築を行う。
分散型の基盤システムアーキテクチャ
共通
基盤
アプリ
ケーション
(個別シ
ステム)

カタログ提供（領域別基盤、データの所在とアクセス方法の共有）

地図・ＧＩＳ領域
防災

BIMデータ連携

AR･･･

システムカタログ

地下埋設物管理領域

自律移動モビリティ（飛行体）領域

埋設物 マシン外部
照会 ガイダンス ビュアー

UTM

･･･

UTM

UTM

データカタログ･･･

共通ソフトウェアライブラリ
データ検索・参照用ライブラリ

空間ID共通インタフェース（データ・メタデータ検索・参照用）･･･
地図・ＧＩＳ
基盤システム･･･
地下埋設物管理基盤システム

データ・
メタデータ

データ・
メタデータ

･･･
自律移動モビリティ
基盤システム

データ紐付け用ツール

空間IDルール

データ・
メタデータ

空間の分割方式

空間ID共通インタフェース（データ紐付け用）

共通IF
データ
提供者

カタログ

共通基盤システム

共通IF

領域別
基盤

領域横断の協調領域の機能（案）

データ・メタデータ定義方式
空間ボクセルへの情報付与方式

2D地図
3D地図

建物等
情報

業界別の
地物情報

静的情報（例）

気象
情報

モビリティ
動態情報

通信
状況

動的情報（例）･･･

時間・精度管理規定

認証、開示範囲、データ真正性確保

共通基盤の機能として、領域間の共通機能やデータの所在を共有可能なカタログは必須とし、今後の実証結果により機能拡張を進める。
Copyright © 2022 METI / IPA54

5-3 共通ライブラリ： (1)ライブラリ整備の概要
領域横断で利用される共通ライブラリは、今後の普及展開に向けて、より多くの開発者・利用者の獲得が重要となる。以下のレイヤに分類し、レイヤごとに方針を整理したうえで段階的な拡張を検討する。
◆基本ライブラリ
・整備中の機能-ジオメトリの空間IDへの変換/逆変換機能
・今後整備が必要と思われる機能-基本ライブラリの組み合わせによる-領域別拡張ライブラリの横断的な共通機能◆領域別拡張ライブラリ
・ドローン、ＧＩＳ、地下埋設物の各領域別に必要となるライブラリの要件は、実証と連携してプロジェクト第2期で検討する③個別機能（競争領域）②領域別拡張ライブラリ

拡張①基本ライブラリ

領域別

・・

拡張

◆個別機能（競争領域）
・利便性、付加価値機能・非機能対応（性能、スケーラビリティ、運用性等）
Copyright © 2022 METI / IPA

55

5-3 共通ライブラリ： (2)ライブラリへの要求と検討状況（1/2）
領域横断の利用を見込み、先行的に整備する共通仕様ライブラリの開発・提供条件については以下の通り検討中。共通性が高く実証に必要な最小限の機能の実装を目指す。
番号

要求条件

要求に対する前提条件

検討状況（7月時点）

1

オープンソースとして提供され、ドメイン横断で共通的に頻度高く利用される機能を実装すること・実装する機能及び各機能の仕様についてはDADC/実証事業者間で協議を行い定義する（実証対象の全てのユースケースで共通的に利用される最小限の機能を実装）
・実装にあたっては、市中のOSSライブラリの活用も可能とする・実装対象とした機能については、実証用基盤システムに組み込み実証で検証を行う
・ユースケース個別に利用される機能の実装は今後の拡張対象候補とする・実証事業者側で仕様案を検討済
・実装言語の前提を置いたうえで利用予定のOSSライブラリは調査済
・実証ユースケース中の利用シーンを確認中

2

再配布可能な形式かつ、利用側に構築の負担をかけない形で提供されること・計算式のみで演算可能な機能のみを対象とする（≠データベース構築を必要とするシステムとしての提供）
・機能要求の実装を優先し、非機能要求（特に性能、拡張性）については利用側で対応する

・左記前提で実証事業者で実装案を検討済

3

共通的に利用される定義情報も同時に配布されること

・地表面等が共通属性として利用される想定があるが、膨大なデータ量となることが想定されるため、共通ライブラリの開発において、共通属性のデータ整備は対象外とする・高さ基準の変換に必要なデータの扱いは別課題として継続管理

4

複数のプログラム言語で提供されること

・多数のプログラム言語での実装が利用の幅を広げる可能性はあるものの、言語の数分だけ開発、試験、運用が発生するため、スケジュール・コストに影響がある。そのため、本実証で最も利用可能性の高い言語1つのみの実装とし、その他の言語での開発は対象外とする・短期間での実証及び、今後の普及を考慮し、開発者を確保しやすく可
読性の高い実装言語として、今年度の実証においてはPython言語による実装を行う
Copyright © 2022 METI / IPA56

5-3 共通ライブラリ： (2)ライブラリへの要求と検討状況（2/2）
領域横断の利用を見込み、先行的に整備する共通仕様ライブラリの開発・提供条件については以下の通り検討中。共通性が高く実証に必要な最小限の機能の実装を目指す。
番号

要求条件

要求に対する前提条件

検討状況（7月時点）

5

利用者側で改変を可能とするため、実行形式のプログラ
ムだけでなくソースコード、設計ドキュメントも提供されること（ただし、改変は自己責
任）・著作権、及びOSSライセンス種別を設定する必要があるため、DADC/実証
事業者との協議事項となる・改変を前提とした非コピーレフト型のライセンスの設定を想定（MIT License、
Apache License、BSD License等）
・市中のOSSライブラリを活用する場合も、同様のライセンスのものを選定する・実証事業者側で非コピーレフトライ
センスを想定して実装検討、ライブラ
リ選定を実施中・OSS化した後の運用イメージ・普及展開イメージをデジタル庁/DADCで検討予定

6

オープンソースとしての提供後も利用者へのサポートや継続的機能追加が提供されること・実証事業期間中に発生した不具合の修正は、本実証で使用する範囲に対して実施（活用する市中OSSライブラリ側で発生した不具合については不具合解決を保証できないため、利用側でも回避策を検討する）
・次年度以降は別途保守の委託業務等により継続される前提とする

・次年度以降の扱いは番号５と合わせて検討予定7

ソフトウェア/ドキュメントの品
質は一定の品質基準を満たしていること・提供するソフトウェアの品質指標/品質基準及びドキュメントの記載レベルについてもDADC/実証事業者で協議の上決定する

・ドキュメント記載レベルは実証事業者側でサンプル等で今後確認予定
・品質基準については、仕様が確認できた後に実証事業者に確認・協議
予定

Copyright © 2022 METI / IPA

57

5-3 共通ライブラリ： (3)実装方式案
領域横断で最も共通性の高い機能の一つとして「ジオメトリと空間IDの変換」が挙げられる。データベース参照を必要としない再配布可能な形式とするため、計算式のみで演算可能な実装方式を検討する。
地下設備登録時(登録)例）地下管路ソース
データ

掘削範囲指定時(参照)

空間ID
DB登録/
参照

属性
データ

3次元
ジオメトリ
データ
・点情報
・シンプルな立体形状 等空間ID
データベース
ジオメトリ⇔
空間ID変換基盤データ（要検討）・地表面・建物 etc

共通仕様ライブラリ
先行整備対象

データベース参照を必要としない
再配布可能な形式で実装予定
例）掘削範囲空間ID
配列

地表面等の共通的な基盤データ整備は別途
検討予定

空間ID
定義情報
Copyright © 2022 METI / IPA

58

5-3 共通ライブラリ： (4)領域横断で利用を見込む共通機能(1/2)
想定されるユースケースを踏まえ、領域横断で利用を見込む共通機能は以下の通り。まずはシンプルな形状から対応し、複雑な形状は下記の組み合わせによって対応する。
No.

分類

想定する利用
シーン・用途

主な入力データ

主な出力データ

1

ジオメトリ
⇒空間ID

点座標（複数）を空間IDに変換する

緯度・経度・高度の配列

空間IDの配列

実装イメージ

Input

1つ以上の
点座標群

2

ジオメトリ
⇒空間ID

閉塞範囲（穴の開いている箇所を除く）を含む空間を
空間IDに変換する

緯度・経度・高度の配列

空間IDの配列

Input

三角形ポリゴンの
集合

3

ジオメトリ
⇒空間ID

ウェイポイント配列を空間IDに変換
する（複数の点座標を直線で繋ぎ、太さを持たせた形状）

緯度・経度・高度の配列、直径

空間IDの配列

Input

レベルM

レベルN

レベルM

レベルN

レベルM

円柱の中心の接続点/ レベルN
円柱の直径（半径）Output
空間IDリスト{XXX}
空間IDリスト{XXX1, XXX2, XXX3}

Output
空間IDリスト{XXX}
空間IDリスト{XXX1, XXX2, XXX3}

Output
空間IDリスト{XXX}
空間IDリスト{XXX1, XXX2, XXX3}
Copyright © 2022 METI / IPA59

5-3 共通ライブラリ： (4)領域横断で利用を見込む共通機能(2/2)
想定されるユースケースを踏まえ、領域横断で利用を見込む共通機能は以下の通り。まずはシンプルな形状から対応し、複雑な形状は下記の組み合わせによって対応する。
No.

分類

想定する利用
シーン・用途

主な入力データ

主な出力データ

4

ジオメトリ
⇒空間ID

3次元の構造物情報（シェープファイル形式）を空間IDに変換する

シェープファイ
ル形式の3Dデー
タ

空間IDの配列

実装イメージ

Input
ーー
ーー
ーー

.shp

レベルM

Output
空間IDリスト
{XXX}

.dbf等

空間IDリスト{XXX1, XXX2, XXX3}

レベルN
構造物情報
（シェープファイル形式）

5

6

7

周辺空間ID取得

周辺空間ID
取得

空間ID⇒ジ
オメトリ

点座標の周辺の空間を空間ID（6個または8個）に変換する

緯度・経度・高度

空間IDを指定して周辺の空間の空間
ID（6個または8個）に変換する空間ID空間IDから空間ボ
クセルの頂点の座標（8点）に変換す
る

空間ID

空間IDの配列

Input

Output空間ID｛XXX｝

空間IDリスト{XXX1,
XXX2,
XXX3
・・・}

空間IDの配列
指定する空間ID（座標の場合No1で変換）

緯度・経度・高度の配列指定した空間ID周辺の空間ID取得Input

Output空間ID｛XXX｝

8つの頂点の座標
Copyright © 2022 METI / IPA

60

5-3 共通ライブラリ： (5)個別論点(1/3)
共通ライブラリの機能は単純な機能に限定されているが、現実の複雑なデータに対応可能か。
・3角形ポリゴンの集合体で複雑な形状も表現することは可能
・一方で複雑な形状を正確に再現することは空間インデックスとしての役割と相反する・複雑な形状に対応すればするほどライブラリ開発者/利用者のコストもかかるため、空間IDデータ整備〜空間ID利用において“適度な抽象度”で管理するラインを実証を通じてドメインごとに検討していく
・複雑な形状が必要な場合、原典データへの参照情報を属性として保持することや、形状の抽象化により過大・過少に空間ボクセルへの紐づけが行われる想定で属性の付与・検索方法を考慮するーーー

形状の抽象化

複雑な形状

利用時の考慮

シンプルな形状で管理

原典データへの参照

実証を通じてドメインごとに事例を蓄積する

周辺空間ボクセルの属性抽出 Copyright © 2022 METI / IPA61

5-3 共通ライブラリ： (5)個別論点(2/3)
通れる・通れないなど属性を紐付ける機能も今後検討が必要ではないか。
・公共空間においては共通属性として利用される可能性は高い
・一方でユースケースごとに通れる・通れないの条件は異なる（空間の広さと移動体の大きさ）
例：
床面移動：歩行空間、サービスロボット移動可能空間、自動運転車、、、
空中移動：ドローン飛行可能空間、、、
・ユースケース実証を通じ、以下の内容について検討を進める
・領域別基盤システムで利用する属性の共通項の抽出・通れる・通れない属性を付与するための元データの収集や効率的なデータ整備手法の検討

Copyright © 2022 METI / IPA62

5-3 共通ライブラリ： (5)個別論点(3/3)
共通ライブラリの仕様については、DOMの仕様のように特定の言語に依存せずメソッドやプロパティを定める方法で定義すると良いのではないか。
以下の手順で検討を進めていく。
＜検討手順＞
・実証実施に必要な最小限の範囲において、特定言語での実装を行う
・共通となる機能を実証を通じて明らかにする・DOMの仕様等も参考に、言語に依存しない抽象化した定義を行う
・抽象化した定義と実装サンプル（OSS）をセットで公開する・実装サンプルを基にした仕様の改良、あるいはDOM等の定義による他言語での実装＜検討手順イメージ＞共通ライブラリ案

実証事業で
実装・利用

特定言語による実
装サンプル
セット

DOM等の
定義

仕様の改良
OSSとして公開
他の言語での実装
Copyright © 2022 METI / IPA63

5-4 共通インタフェース： 共通インタフェースが提供する機能（1/2）
ネットワークに分散した空間ID情報を検索・取得するためのインタフェースについて、基本的なインフェースは共通化して規定する一方で、空間IDは様々な領域で利用されることを踏まえ、拡張性・柔軟性を確保する仕組みを備えることを目指す。
空間ID DB（領域別基盤）

上位サーバー

登録（紐付け）

メタデータ検索各種ファイル形式(CityGML,ShapeFile,,,)Object-handle[空間ID検索]
利用者

空間ID DB

検索条件(メタデータ/領域)
Object-handle*

利用者
参照 （個別システム）[空間IDコンテンツ流通]
利用者

ネットワークに分散したシステムの連携
空間ID DB登録
探索

空間ID DBから
空間IDの情報を検索

空間IDの参照

コンテンツを登録（紐付け）

空間IDコンテンツ流通

手続き

単一(unary)/分割設定/分割応答/通知(push)

プロトコル

http / gRPC

認証

検索条件(Object-handle*)
空間IDコンテンツ群

サービス分類空間ID検索分散管理（レジストラー、メタデータ）（ディレクトリ管理）

空間ID DB

コンテンツ登録

パラメータを規定
・サービス毎に分類
・拡張性・柔軟性（ユーザ定義）を確保
共通の手続きを規定
・取得・登録（データ分割含む）
・通知（変化時通知、更新差分通知）*Object-Hnadle（オブジェクトハンドル）
オブジェクト指向のプログラミング言語で使用される。操作対象とするオブジェクト（画面、ファイル、ＤＢ等）を一意に区別する識別子を指す。
本報告書では、領域別基盤内で、利用者が指定した空間ID集合や空間ボクセルデー
タ集合を示す一意の値を指す。

汎用的なプロトコルを適用
・サーバーシステム間：gRPC・クライアントサーバ：https + JSON query, SSE
Copyright © 2022 METI/IPA

64

5-4 共通インタフェース： 共通インタフェースが提供する機能（2/2）
参考例：パラメータセマンティクス概要草案

空間IDは次の2つの利用方法を想定する。
・対象領域を指定する（主にリクエストで利用）。
・建造物等の対象物を表現する（主にレスポンスで利用）。
リクエスト

サービス分類
分散管理

空間ID検索空間IDコンテンツ流通

コンテンツ登録

宛先
共通基盤システムに基づく
分散サーバ（上位サーバ）

空間ID DB

空間ID DB

空間ID DB

レスポンス

パラメータ

備考

パラメータ

領域

事業領域等

空間ID DBアドレス

空間ID検索のための情報

区域

空間IDで表現

種別

地物・気象等のデータ種別

メタデータ

検索のためのクライテリア

Object-handle群

空間IDコンテンツをまとめる識別子

区域

空間IDで表現

種別

地物・気象等のデータ種別・ユーザ拡張可

Object-handle

空間IDコンテンツ指定

CityGML
ShapeFile

各種3D表現形式

位置情報

3D表現形式の示す原点座標

ソースリンク

登録するソースリンク（Object-handleのひとつ）

備考

空間ID群

Objectを表現する空間ID群

属性情報

Objectに属する情報・ユーザ拡張可ー

空間IDに変換するなどしてデータを保持

空間ID検索+空間IDコンテンツ流通ハイブリッド形式（空間ID検索リクエスト＋空間IDコンテンツ流通レスポンスによりObject-handleを介さない形式）についても規定する。
上記に基づきパラメータのシンタックスを定め複数のインタフェースを規定する。
パラメータ定義はprotocolBuffer(gRPC)等で定義し、これを公開することで、拡張性を保つ（案）。
Copyright © 2022 METI/IPA
情報流通においては、サーバー間gRPC、サーバークライアント間にREST(http/JSON)を適用する（案）。

65

5-5 基盤システム構成（例）： (1)ドローン運行管理領域用
ドローン向け基盤システムは、地形・建物等に関する静的データに加えて、気象や事業者による空域利用等の動的データについて、空間ＩＤを共通インデックスとして、検索・統合して提供する機能を持つ想定。
基盤システムは協調・競争領域機能をモジュール化・組み合わせにより提供する想定

協調領域

UTM 3
UTM 2

データ
利用者
（UTM）

経路生成

共通ソフトウェアライブラリ

地物

競争領域

災害、天候通知

基盤システムは自律・分散・協調的に、複数設置される想定

飛行経路ロギング

空間ID共通インタフェース(データ・メタデータ検索・参照用） 領域別拡張インタフェース

データストレージ

データ統合機能
空域B

空域A利用事業者

モビリティ
向統合
データ
生成機能

データ・メタデータ定義方式
モビリティ向け統合データ

サービス依存プロトコル変換
共通ソフトウェアライブラリ

CityGML※⇔ 空間ID変換

緯度経度⇔
空間ID変換

経路情報の空間ID変換空間ボクセルへの情報付与方式
共通インターフェース定義

空間ID共通インタフェース（データ紐づけ用）

協調領域

空間IDルール（例）
空間の分割方式

空間ID
空間ID
空間ID

地形情報
天候情報
飛行情報

時間・精度管理規定
認証、開示範囲、データ真正性確保

インデックスデータ

領域別拡張機能凡例
領域横断の共通機能
領域別に実装される機能※国土交通省が提供するCity GML形式の3D都市モデル（PLATEAU）等を想定

データ提供API(既存)
データ提供

データ
提供
者

地形・建物情報

地形・建物情報※
管理者/提供事業者

データ提供
天気予報

気象情報提供事業者

データ提供
飛行空域/経路情報

無人航空機管制サービスUTM

将来的にはデータ提供者側シ
ステムで空間ID の共通仕様
ライブラリを実装することで、デー
タ提供者とデータ利用者が直接データ連携することも想定
Copyright © 2022 METI / IPA66

5-5 基盤システム構成（例）： (2)地図・GIS領域用
地図・GIS領域用基盤システムは様々な空間データを空間IDと紐付けて、空間IDを利用するための協調
領域/競争領域機能をデータ利用者のシステム/クライアントに提供する想定。
共通ソフトウェアライブラリ
緯度経度⇔
空間ID変換

図形⇔
空間ID変換データ
利用者
システム/クライアント

災害情報共有基盤システムは自律・分散・協調的に、複数設置され、協調領域機能の他に、基盤システム毎に固有の競争
領域機能を提供する想定

建物内ナビゲーション

施設管理

CityGML ⇔空間ID変換

領域別拡張インタフェース

空間IDルール（例）空間ID共通インターフェース（データ・メタデータ検索・参照用）

タフェース
協調領域機能システム固有競争領域機能

空間の分割方式

ボクセルによるルーティング

幾何形状情報及びメタデータ定義方式

ボクセルによる
災害リスク解析

共通ソフトウェアライブラリ

緯度経度⇔
空間ID変換空間IDによる
レコード検索属性による
空間ID検索空間ボクセルへの情報付与方式
共通インターフェース定義
空間ID 地形情報
空間ID 災害情報
空間ID BIMデータ

時間・精度管理規定
地理空間データ

認証、開示範囲、データ真正性確保

空間IDの協調領域の機能を提供するインターフェースやツー
ルは空間IDの共通ライブラリを活用して開発される想定

3次元空間ID DB ストレージ

メタデータインデックス

空間ID共通インターフェース(データ紐づけ用)

共通ソフトウェアライブラリ

凡例
領域横断の共通機能

領域別に実装される機能※国土交通省が提供するCity GML形式の3D都市モデル（PLATEAU）等を想定

データ提供API(既存)
データ提供

データ
提供者

例: 地形・建物情報

地形・建物情報※
管理者/提供事業者

データ提供

データ提供

例：災害情報例：統計情報

災害情報提供事業者

統計情報提供事業者

将来的にはデータ提供者側シス
テムで空間ID の共通仕様ライ
ブラリを実装することで、データ提供者とデータ利用者が直接データ連携することも想定
Copyright © 2022 METI / IPA67

5-5 基盤システム構成（例）： (3)地下埋設領域用
地下埋設領域用基盤システムは地下埋設物等の事業者設備データの登録や、掘削範囲を指定する際の検索機能を複数のWebアプリケーションから利用するための機能を提供する想定。
共通ソフトウェアライブラリ
緯度経度⇔
空間ID変換

図形⇔
空間ID変換データ
利用者
システム/クライアント

埋設物照会業務基盤システムは自律・分散・協調的に、複数設置され、協調領域機能の他に、基盤システム毎に固有の競争
領域機能を提供する想定

建設機械マシンガイダンス

CityGML ⇔空間ID変換

領域別拡張インタフェース

空間IDルール（例）
空間の分割方式
幾何形状情報及びメタデータ定義方式
空間ボクセルへの情報付与方式

空間ID共通インタフェース
共通ソフトウェアライブラリ（データ・メタデータ検索・参照用）

システム固有競争領域機能
埋設物
存在有無判定協調領域機能図形⇔
空間ID変換

掘削リスク
算出

空間IDによる
レコード検索属性による
空間ID検索共通インターフェース定義
空間ID
空間ID
空間ID

時間・精度管理規定
ジオメトリデータ

認証、開示範囲、データ真正性確保

管路情報
地表面情報
建物情報

3次元空間ID DB ストレージ

メタデータ インデックス

空間ID共通インターフェース(データ紐づけ用)

凡例
領域横断の共通機能
領域別に実装される機能

データ提供API(既存)
データ提供

データ
提供者

空間IDの協調領域の機能を提供するインターフェースやツー
ルは空間IDの共通ライブラリを活用して開発される想定

例: 地形情報

共通ソフトウェアライブラリ

データ提供
例：地下埋設設備（管路、マンホール等）
位置基準

地形情報
管理者/提供事業者

設備管理事業者（上下水、電力、ガス、通信）

将来的にはデータ提供者側シス
テムで空間ID の共通仕様ライ
ブラリを実装することで、データ提供者とデータ利用者が直接データ連携することも想定
Copyright © 2022 METI / IPA

68

5-6 メタデータ項目の定義
空間IDに紐付けをしたデータセットの効率的な管理・検索を行うためのメタデータの項目を定義。
項目案の必須・条件付き必須項目は全領域共通として、各システム領域固有で必要な項目を実証を通して検討。
メタデータ項目案

メタデータとはNo

データ本体に関する付帯情報が記述されたデータ◎必須、〇条件付き必須、△任意

項目

説明

レベル

1

データ名

データの名称◎2

概要

データの内容の概要説明◎

メタデータの利用例

3

主題分類

データを分類する主題△

メタデータ項目（主題分類、登録者、データの範囲など）を対象とした検索を行うことで、利用目的に合ったデータセットを見つけ出すことができる。
（データのポータルサイトにおけるデータ検索に活用されている。）

4

空間IDへの登録者*

空間IDへのデータの紐付けを行った事業者

◎

5

キーワード

データの検索に使用するキーワード

△

6

登録日付*

空間IDへのデータの紐付けを行った日付◎

7

データの利用制限

データ利用上の制約条件（例：非商用に限る）△

8

データの範囲（水平方向）

最小・最大緯度、最小・最大経度◎

メタデータの利用イメージ

9

高さ情報の有無*

データに高さ情報が含まれているかの有無◎

10

データの範囲（鉛直方向）

最低・最高標高値（No9が「有」の場合必須）

〇

11

高さの基準

標高の基準面（No9が「有」の場合必須）〇

12 データの範囲（時間要素）

データの対象時期・期間△

13

空間ID登録ズームレベル*

空間IDのデータの紐付けを行った基準となるズームレベル◎

14

全データを包含する空間ID*

全データ範囲を包含する最上位レベルの空間ID（要自動計算）△

15

実データの所在*

実データの所在（システム内、システム外）◎

16

ソースデータ名

ソースデータの名称（No14が「システム外」の場合必須）〇

17

ソースデータの作成者

ソースデータを作成した機関（No14が「システム外」の場合必須）〇

地理情報のメタデータ標準

18

ソースデータの所在

ソースデータの提供先(URL)（No14が「システム外」の場合必須）〇

・ 国際標準：ISO 19115
・ 日本版メタデータプロファイル：JMP2.0⇒ JMP2.0のメタデータ項目を参考に案（右表）を作成

19

ソースデータ形式

ソースデータのフォーマット

△20

ソースデータの座標系

ソースデータの座標系△

21

ソースデータの精度

ソースデータの縮尺レベル、解像度△

22

ソースデータ収集期間

ソースデータが収集された期間①メタデータの検索

メタデータ

各データセット②該当データセットのリスト③実データの検索＊JMP2.0にはない空間ID独自のメタデータ項目

Copyright © 2022 METI / IPA△69

5-7 空間ボクセルデータ項目： (1)ドローン運行管理
準動的・静的な情報についても、飛行時には計画時からの変化に対して、即時の共有が求められる。このため、3次元空間情報基盤システムの即時情報共有対象データの軽量化等を考慮していく必要がある。
データ項目

動
空間ID

準
動

機能要求

協調

競争

更新頻度

• 有人機情報• 無人機情報• 緊急情報(飛行禁止
エリアの設定)• 飛行計画からの更新
情報

• 秒〜分
（飛行時）

• 飛行計画情報• 気象情報• 人流情報• 地物(鉄塔・送電線・建物等)• 地形情報(河川、道路等）• 通信カバレッジ情報• 衛星測位情報• 時間〜日（飛行計画時）• 日〜年（飛行計画時）静• 規制情報(飛行禁止/制限空域の設定)• 地物情報(PLATEAU)• 地形情報(国土地理
院)

今後の
検討事項

• データの信頼性担保や、指標を誰が整備・管理するか。
• 信頼性担保のための指標を情報提供者と利用者で共有するための仕組みをどうするか。

・競争領域データは開示範囲を情報提供者が制限・協調領域データは基本的には広くアクセスを認める(一部規制情報でアクセス制限する必要のある情報についてはユー
スケース具体化が必要)

・地物情報は空間の占有/非占有としての表現が必要・人流/統計等の2次元の情報と、空
間占有/気象/電波(通信/衛星測位)
状態等の3次元で表現される情報の統一的な空間への紐づけが必要・協調領域で変換(CityGML→空間占有情報)の必要となるデータについては変
換済みデータの一時保存が必要

・競争領域データ(気象/通信カバレッジ/
衛星測位/人流情報)については情報提供者から直接入手

・飛行計画時は情報利用者からの検索(REST API等)
・飛行時は飛行計
画時からの差分/変化の即時的な通知(gRPC、MQTT等)• 飛行計画時、飛行時に情報を共有するための情報検索、通知用I/Fラ
イブラリの仕様はどうするか。

なお、飛行時に必要となる有人機/無人機等の動態情報については、ADS-B/Remote ID等既存共有方式との連携/役割分担、飛行計
画情報の共有について、FIMS等の既存方式との連携/役割分担など、既存方式との連携も必要になると考えられる
Copyright © 2022 METI / IPA
70

5-7 空間ボクセルデータ項目： (2)地図・GIS
地図・GIS分野において、動的なユースケースについては、高頻度のデータ更新が求められる。それに応じて、3次元空間情報基盤システムに対する性能要求も高度化していく。
データ項目

動
空間ID

準
動
静
今後の
検討事
項

•

協調

競争

緊急警戒情報• 気象情報(局地)• ジオフェンス(通行不可エリア)• 建物・地物• 広域ハザード情報• 統計情報• 気象情報(広域)• 人流・混雑情報• 地図POI• 物件情報

機能要求
更新頻度

アクセス

登録・紐付・統合保持要求(検索・通知)

• 分〜
時間

• 時間〜
日

• 月〜年

• データの種別に応じたアクセス・認証権限設定• データの真正性・鮮度の担保

・競争領域
データは認
証・開示範
囲に制限

・協調領域
データは広くア
クセスを認める

・汎用的な言語でデータの登録・空間
ID変換が可能なイン
ポートツール・データ提供側の環境によってはファイル交換にも対応・高速処理DB・更新情報を保持するキャッシュ機能・リクエストに対して高速応答可能な
REST API(HTTP/HTTPSなど)
・緯度・経度や属性など複数パラメータで検索可能
なAPI• 高頻度の更新が必要なアプリケーションにおける基盤側のDB
やインターフェースの非機能・性能要件
Copyright © 2022 METI / IPA71

5-7 空間ボクセルデータ項目： (3)地下埋設物管理
地下埋設物に関しては静的データとして管理され、月~年単位で定期的に更新される。地下埋設工事が行われた際に、建設機械で取得された掘削後の地面形状等が準動的データとして管理される。
データ項目

動
空間ID

準
動
静
今後の
検討事
項

機能要求

協調

競争

更新頻度

ー

ー

ー

• 掘削後地面形状• 地下埋設物位置• 占用事業者名• 工事情報• 設備情報• 埋設深度•日• 月〜年• 今後災害対策における設備復旧利用を想定した場合、動的情
報として気象・災害情報（土砂崩れ・浸水・津波エリア情報）
を協調領域として空間ボクセルに紐づける必要がある。

アクセス

・協調領域
データは埋
設物管理
事業に関係
するものに、
認証・開示
範囲を制限
・競争領域
データは、道
路管理者
及び自社設
備の情報の
み利用可能

登録・紐付・統合

・地下埋設物位置は空間の占有/非占有に変換して空間ボクセルに紐づけ
・掘削後地面形状は、建設機械管理システム
から、地面点群情報を
空間ボクセルに紐付け

保持

通信・検索

・協調領域及び競争
領域データについては
情報提供者自らが登録

・情報利用者からの検索(REST API
等)• 地下埋設物情報及び掘削後地面形状を共有するための情報検索用
I/Fライブラリの仕様を検討

Copyright © 2022 METI / IPA72

5-8 空間情報の検索方法
空間情報の検索条件となる項目の洗い出しを行い、実証を通じて実際に発生する検索パターンの特定を行う。今後、共通ライブラリの整備や検索方法の整理を進めていく。
検索条件例

検索結果例

大分類

中分類

検索条件

分類

検索結果

形状情報

2次元形状

ポイント、ライン、ポリゴン

基本情報

結果コード（正常、異常）

3次元形状

ポイント、ライン、ポリゴン

空間ID

空間ID、空間ID配列

粒度情報

空間ボクセル粒度

地物ID（ユースケース毎に設定）

ID

空間ID、空間ID配列

レベル

レベル番号

バッファ

バッファタイプ、バッファサイズ

属性（ユースケース毎に設定）

時間軸

時間、世代、バージョン等

住所

地名、郵便番号、、、

・・・

・・・

ID

オプション

意味情報

・・・

レベル番号

地物ID
属性

属性有無
属性値

リンク

詳細データリンク先
他ドメインリンク先

・・・

・・・

Copyright © 2022 METI / IPA73

5-8補足：提供データの粒度と検索者の要求粒度が異なる場合の取り扱い方式
論点：データ提供側と検索者の要求粒度が異なる場合、下記の考え方が存在する。
①空間ボクセルの親子関係を考慮した検索結果を返却する②検索者はデータ提供側の粒度を意識して検索を行う
課題認識

検討状況

レベルN

検索側の要求親子

レベルN+1

対応案

メリット

デメリット

①空間ボクセルの親子関係を考慮した検索結果を返却する

・データ提供側/検索側のレベルを意識せず利用できる

・検索側の要求の粒度が低い
場合、粒度の高い結果が混在する可能性がある②検索者はデータ提供側の粒度（レベル）を意識して検索を行う

・データ提供側が意図した利用用途で利用される・検索時の粒度ミスマッチによる利用機会損失検討の方向性
親子

データ提供側の登録先

レベルN+2

・検索時に親子関係をたどったデータの存在確認や属性の継承を行うユースケースの検討を行う
・今後の実証を通じ、異なる粒度の空間ボクセルの利用シーンを明らかにし、課題の抽出と対応策の検討を実施する
Copyright © 2022 METI / IPA

74

6

今後の検討事項
6-1 本プロジェクトにおける今後の取組
6-2 プロジェクト第２期の検討事項（予定）75

6-1 本プロジェクトにおける今後の取組
プロジェクト第１期の成果をもとに、プロジェクト第２期では実証事業者と協力して空間データ仕様等の具体化や空間情報基盤の運用方法、普及策の検討を進める。また、地上モビリティや海上用途の検討を行う。
12月

2022年度4月

プロジェクト第１期

DADC
アーキテクチャ設計

プロジェクト第２期

プロジェクト第３期

空間定義概要空間データ仕様具体化

共通機能概要共通機能具体化（３次元空間情報
プロジェクト）

実証

1月

8月

デジタルツイン構築事業(デジタル庁)

主に非モ
ビリティ
分野

産業DX事業(経済産業省
NEDO)

主にモビ
リティ分
野

202３年度以降
4月

データ・機能仕様書β版

仕様更新・拡張
機能拡張・更新…

標準化、及び事業モデルを含む普及方法の具体化

空間情報基盤運用ガイドライン制定

地上モビリティ向け等の空間情報定義

地上向けの仕様具体化等• 実証用基盤システム開発• 実証用データ・メタデータ整備• アウトカム指標・目標を設定• 実証用基盤システム開発• 実証用データ・メタデータ整備• アウトカム指標・目標を設定• 実証実施・成果確認• 協調領域のOSS化• 実証実施・成果確認• 協調領域のOSS化

2024年度
末まで継続

Copyright © 2022 METI / IPA76

6-2 プロジェクト第２期の検討事項（予定）
プロジェクト第２期では、第１期の検討を具体化し、データ・機能仕様書として取り纏める。また、標準化施策や空間情報基盤の運用についても検討する。更に地上モビリティを中心にユースケースを追加していく。
プロジェクト第２期の検討事項（予定）
プロジェクト第２期のテーマ

空間データ仕様具体化
共通機能具体化

プロジェクト第１期を引継ぎ、ドローン、ＧＩＳ、地下埋設物の各領域について、データ仕様を具体化する。

データ・機能仕様書β版

標準化、及び事業モデルを含む普及方法の具体化
地上モビリティ向け等の空間情報定義

プロジェクト第１期を引継ぎ、ライブラリ機能や共通インタフェースの仕様を具体化する。
グローバル標準化について調査と検討を行う。

6.2
(1)

空間情報基盤の運営方法等の事業モデルを
検討する。

6.2
(2)

空間情報の真正性を保つための事業者認定
等の具体的施策を検討する。

6.2
(3)

歩道走行ロボット、自動運転車、海上交通のユースケースを追加する。

6.2
(4)

Copyright © 2022 METI / IPA77

6-2(1)空間IDの普及・社会実装に向けた標準化の進め方①• 空間IDの標準化戦略において、国内外でのデジュールスタンダードの獲得と並行して、よりスピード感のある、デファクトスタンダードを確保することが重要。
• そのため、まずはデファクトスタンダードの実現に向け、ステークホルダーを巻き込んだ実証実験を進めつつ、並行して国内外のサービスや標準化の動向やユースケース等を見据え、諸外国に対して積極的に情報発信を行う。その上で、デジュールスタンダードの確実な獲得を目指す。
デファクトスタンダード
市場での普及を通じての事実上の標準

デジュールスタンダード
公的な標準化組織が開発する標準規格

ステークホルダーを巻き込んだデファクトスタンダード化
1）規格検討段階からの関係企業・団体や省庁との共同検討
2）実証・研究開発段階からのユースケースを想定した開発
例）自律移動するモビリティの運行管理支援
GIS における3次元地理空間情報の重畳の簡易化
地下埋設物の照会や建設機械の掘削支援 等

国内外のサービスや標準化の動向把握及びデジュールス
タンダードの獲得
1）国内外のサービスや標準化の動向把握、実証結果を踏まえたユース
ケースの整理、情報発信及び諸外国との仲間作り2）ISO、国連Open GIS イニシアティブ、OGC等に対する提案
Copyright © 2022 METI / IPA78

6-2(1)空間IDの普及・社会実装に向けた標準化の進め方②
将来ビジョン検討会における議論内容を踏まえて検討のアプローチや具体案を検討中。
第4回 自律移動ロボット将来ビジョン検討会 指摘事項（要旨）⚫ 今後は標準化戦略、海外へのインフラ輸出等も含めた先を見据えた展開が不可欠である。
⚫ デファクトでの世界展開を推進するか、デジュールに持ち込むかはDADCが戦略的に進めるべき。標準化小国/日
本が勝つためにはデジュールが必要ではないか。
⚫ デジュールスタンダードを目指すにしても、関係者の巻き込み（デファクト）が重要である。

⚫ 標準化はミニマルなガイダンスであるべきだが、安全性を担保するためには、ローカルの状況に則した適切なルール作りが必要ではないか。
⚫ 海外展開を見据えると「Why Japan？」という問いにも対応できる強みが必要ではないか。
⚫ 高度な人材育成に繋がるコミュニティ形成や標準化への取組が不可欠。標準化された空間IDを含むパッケージソ
リューションの海外展開が必要ではないか。
⚫ 日本ならではの方向性、認証機関の設立等が必要ではないか。
Copyright © 2022 METI / IPA

79

6-2(2) 空間情報基盤の事業モデル検討
プロジェクト第２期では協調領域の運営方法を中心に検討する。また領域別基盤の運営主体やマネタイズの方法を検討していく。
分散型の基盤システムアーキテクチャ
共通
基盤
アプリケー
ション
(個別シス
テム)

共通IF
領域別
基盤

カタログ提供（領域別基盤、データの所在とアクセス方法の共有）

共通基盤システム
地図・ＧＩＳ領域
防災

BIMデータ
連携

AR

自律移動モビリティ（飛行体）領域

地下埋設管理領域
埋設物
照会

･･･

マシン
ガイダンス

外部
ビュアー

領域横断の協調領域の機能（案）

UTM

･･･

UTM

UTM

カタログ
システムカタログ
データカタログ･･･

共通ソフトウェアライブラリ
データ検索・参照用ライブラリ

空間ID共通インタフェース（データ・メタデータ検索・参照用）･･･
地図・ＧＩＳ
基盤システム･･･
地下埋設物管理基盤システム･･･
自律移動モビリティ
基盤システム

データ・
メタデータ

データ・
メタデータ

データ・
メタデータ

空間IDルール
空間の分割方式

空間ID共通インタフェース（データ紐付け用）

共通IF

データ紐付け用ツール

データ・メタデータ定義方式

データ
提供者

2D地図
3D地図

建物等
情報
静的情報（例）

業界別の
地物情報

気象
情報

モビリティ
動態情報

通信
状況

動的情報（例）･･･

空間ボクセルへの情報付与方式
時間・精度管理規定
認証、開示範囲、データ真正性確保

基盤運営主体やマネタイズ方法を検討
恒常的な運用していく仕組み（ソフトウェアの更新・追加含む）や知財取扱等を検討
Copyright © 2022 METI / IPA80

6-2(3) 空間情報基盤利用者の認定・認証、及びデータ真正性の確保
空間情報を活用したレベル４自律移動モビリティ用途では、誤ったデータの登録や改竄が事故のリスクに直結し得るため、データ登録者の認定等、データ真正性を確保するための施策を検討する。
アーキテクチャ/標準を提供する

経済産業省/デジタル庁/関係省庁
認定基準

認証基準

アーキテクチャ/標準

アーキテクチャ設計
/標準作成

実証事業
/研究開発事業

指定する

認定機関

認定する

認定

事業者
安全性・信頼性のレベルに応じて、ライブラリ提供、認証、認定等を実施認定するシステムを認証する

認証機関
認証

ライブラリ

国際標準化推進仕様を提示するライブラリを提供する
Copyright © 2022 METI / IPA

81

6-2(4) 今後検討していく予定のユースケース
プロジェクト第１期のユースケースに加え、地上モビリティ及び海上交通をユースケースに取り組む予定。

＜プロジェクト第２期より空間情報の検討を開始予定のユースケース＞
１．歩道走行ロボット向け
・「車いすサイズの配送ロボット」が屋外でレベル４歩道走行を行うために必要となる空間情報の整理
・配送ロボットが屋内と屋外を往来するための、屋内空間との情報連携方法を主たるテーマとしたアーキテクチャの検討。
２．自動運転車（レベル４）向け
・自動運転車の安全で効率的な利用を促進するための空間情報の需要調査
・需要調査をもとに、協調型システムのアーキテクチャ検討及び空間IDのユースケース検討。
３．海上交通向け
・海上向け空間情報の需要及び市場規模の調査
Copyright © 2022 METI / IPA

82

APPENDIX83

APPENDIX ： ３次元空間情報基盤の協調領域における検討項目①
３次元空間情報基盤の協調領域として、以下の項目について本プロジェクトでアーキテクチャの具体化を進めている。（プロジェクト第２期で継続検討）
空間IDルール

3次元空間情報基盤（機能）A1 空間の分割（３次元グリッド）方式
A1.1 空間の水平方向の分割方式
A1.2 空間の鉛直方向の分割方式
A1.3 空間IDと座標（経度・緯度・高度）の紐付け方式

B1 共通基盤システムが提供する機能
B1.1 領域別基盤システムおよびデータ提供者の所在を登録・参照・更新・削除する機能（カタログ作成）
B1.2 空間ＩＤから該当する領域別基盤システムおよびデータ提供者の所在を検索する機能（カタログ検索）
B1.3 空間情報のうち共通空間情報の登録・参照・更新・削除する機能（仮：必要性について検証要）

A2 データ・メタデータ定義方式
A2.1 ソースデータ定義（空間情報基盤でサポートするソースデータの種類と形式、および精度）
A2.2 メタデータのデータモデル定義

B2 領域別基盤システムが提供する機能
B2.1 ニーズに応じて空間情報を加工・統合し、検索・参照する機能
B2.2 領域別基盤システム・空間情報の安全性・信頼性を確保する機能

A3 空間ボクセルへの情報付与方式
A3.1 空間ボクセル属性のデータモデル定義

B3 空間ＩＤ共通インタフェース（データ・メタデータ検索・参照用）が提供する機能
B3.1 アプリケーション・基盤間共通I/F（検索・参照用I/F)が提供する機能
B3.2 領域別拡張インタフェース（データ・メタデータ検索・参照用）

A4 時間・精度管理規定
A4.1 時間概念の管理方法および空間ボクセルにおける表現方法
A4.2 データの有効期限および更新に関する規定
A5 認証・開示範囲・データ真正性確保
A5.1 利用者の登録および認証方式
A5.2 データ開示範囲の設定基準
A5.3 データ提供者（事業者・システム）の認定基準・認定方法

B.4 空間ＩＤ共通インタフェース（データ紐付け用）が提供する機能
B4.1 共通インタフェース（データ紐付け用)
B4.2 領域別拡張インタフェース（データ紐付け用）
B5 データ提供者が保持可能な機能（今後整理）

Copyright © 2022 METI / IPA84

APPENDIX ： ３次元空間情報基盤の協調領域における検討項目②
３次元空間情報基盤の協調領域として、以下の項目について本プロジェクトでアーキテクチャの具体化を進めている。（プロジェクト第２期で継続検討）
3次元空間情報基盤（データ）C1 共通基盤システムが収容するデータ
C1.1 領域基盤システム・空間情報の所在情報（カタログ）
C1.2 領域横断で保有すべきデータ・メタデータ（仮：B1.3の要否次第）
C2 領域別基盤システムが収容るデータ
C2.1 データ（領域別システム内）
C2.2 メタデータ（領域別システム内）
C3データ提供者が保持するデータ
C3.1 静的なデータ
C3.2 動的なデータ

Copyright © 2022 METI / IPA85