OGC（Open Geospatial Consortium）が定義する空間データ標準規格

私たちの日常生活に欠かせないWeb地図サービスや、都市計画・防災で活用されるGIS（地理情報システム）。これらがシームレスに機能している背景には、異なるシステムやソフトウェア間で地理空間データを円滑にやり取りできるようにするための「標準規格」が存在します。

本記事では、地理空間情報のオープン規格を策定する国際的なコンソーシアムであるOGC（Open Geospatial Consortium）の基本から、WebGISを支える代表的なデータ規格、さらには近年注目される次世代APIやクラウドネイティブな最新動向までを網羅的に解説します。

OGC（Open Geospatial Consortium）とは？

設立とミッション

OGCは、1994年に設立された非営利の国際コンソーシアムです。世界中の企業、政府機関、研究機関、学術組織が集まり、地理空間データやテクノロジーの「相互運用性（インターオペラビリティ）」を向上させるためのオープンな標準規格を共同で開発・維持しています。現在では、150以上の標準規格が業界の合意（コンセンサス）のもとで策定されています。

ISO/TC 211との強固な連携関係

OGCは設立当初から国際標準化機関との協調を重視してきました。
設立から約2年半後の1997年5月には、国際標準化機構の技術委員会であるISO/TC 211（地理情報/ジオマティクス）との緊密な協調体制を発表しています。
両組織は独立して規格策定を行っていましたが、重複や乖離を避けるためにワークプランの統合と平準化を進めてきました。
具体的には、ISOがより抽象度の高い共通フレームワークを定義し、OGCが実装可能なエンジニアリングレベルの仕様（実装プロファイル）を開発して、それをISO規格（「公開仕様（PAS）」などの仕組み）として取り込むという相互補完的なアプローチを取っています。この30年におよぶ強力な連携により、収集した地理データがグローバルに活用できるインフラが維持されています。

WebGISの基本：WMS（画像）とWFS（生データ）の違い

Webブラウザ上で地図を配信・表示する際、OGCが定義する2つの古典的かつ極めて重要なプロトコルがWMSとWFSです。

【WMS (Web Map Service)】
[クライアント] ----(「Area X」の地図を要求)----> [GISサーバー]
[クライアント] <---(レンダリング済みの画像)--- [GISサーバー] (サーバー側で描画するため高速)

【WFS (Web Feature Service)】
[クライアント] ----(「Layer Y」の生データを要求)---> [GISサーバー]
[クライアント] <---(生の座標データ/GeoJSONなど)--- [GISサーバー] (クライアント側で描画・編集可能)

地図を見るための「WMS」

WMS（Web Map Service）は、クライアントからのリクエスト（指定範囲のバウンディングボックスや座標系）に応じて、サーバー側で空間データを処理・スタイリングし、最終的なラスタ画像を生成して配信する規格です。

メリット
クライアント側のレンダリング負荷が低いため表示が高速です。また、元の生のベクタデータ（座標値など）を直接クライアントにさらすことがないため、セキュリティやライセンス保護の観点でも非常に有利です。

デメリット
クライアント側で図形自体の形を変えたり、動的にスタイルを編集したりすることはできません。

地図データを操作するための「WFS」

WFS（Web Feature Service）は、サーバーの空間データベースから生の座標値（点・線・ポリゴンなどの幾何形状）と、それに紐づく属性情報を抽出し、GeoJSONやGMLなどの形式でクライアントに直接転送する規格です。

メリット
クライアント側で「特定の地点から半径5km以内の施設を検索する」といった高度な空間分析や、動的な色分け、スタイリング変更が自由に行えます。さらに、拡張規格であるWFS-T（Transactional WFS）を利用すれば、権限を持つユーザーがブラウザやアプリを介して、サーバー上の空間データベースのデータをリアルタイムに作成・更新・削除（CRUD処理）することが可能になります。

デメリット
数十万ノードを超える密なポリゴンデータを読み込むと、ネットワーク帯域を圧迫し、クライアント側のブラウザやアプリがフリーズする原因になります。

高速表示を支える「WMTS」

WMSはユーザーが画面を移動（パン）したりズームしたりするたびに、サーバー側でカスタム画像をゼロから動的に生成するため、同時アクセスが増えるとサーバー負荷が急増します。
この課題を解決したのがWMTS（Web Map Tile Service）です。
WMTSは、あらかじめ指定された縮尺ごとに地図を256x256ピクセルの小さな「画像タイル」に切り分けてキャッシュ（またはCDN）に配置しておき、リクエストに応じて即座に配信します。
これにより、サーバーの再描画負荷を最小限に抑え、Google Mapsのようなスムーズなズーム・パン体験を提供します。

実務での「ハイブリッド設計」

実際のエンタープライズWebGISでは、どれか1つの規格に頼るのではなく、複数を組み合わせたハイブリッド設計が行われます。
高速表示が必要な「広域の衛星画像や複雑な背景地形図」にはWMTSを使い、その背景地図の上に重ねる「クリックして情報を表示させたり、フィールドワークで編集したりする特定のデータレイヤ（土地境界、インフラ設備など）」に対してのみWFS（WFS-T）を利用するという設計が、表示速度と機能性を両立するためのデファクトスタンダードとなっています。

オフラインとモバイルで大活躍する「GeoPackage（GPKG）」

インターネット環境が十分に確保できない場所や、モバイル端末で大容量の空間データを扱いたい場合に欠かせないのがGeoPackage（GPKG）エンコーディング規格です。

開発された背景と課題

従来のGISシステムでは、アプリケーションごとに独自のプロプライエタリなデータ形式が採用されていることが多く、データの共有には中間フォーマットへの変換、レプリケーション、同期といった煩雑なプロセスが必要でした。
また、モバイル端末はストレージ容量が限られており、ネットワークが不安定または切断されたオフライン環境（Disconnected Environment）では、これらの個別データを持ち歩くこと自体が困難でした。

SQLiteベースのポータブルな単一ファイル構造

GeoPackageは、これらの課題を解消するため、世界的に広く使われている軽量な関係データベース「SQLite 3」をベースとして定義されたプラットフォーム非依存のバイナリファイル形式です。
ひとつの「.gpkg」ファイルの中に、以下のようにベクタ幾何形状、ラスタタイルマップ、属性テーブル、およびそれらを管理するシステムメタデータがすべてパッケージ化されて収められます。

【GeoPackage (.gpkg) ファイルの内部イメージ】
📂 gpkg_spatial_ref_sys（空間参照系メタデータ）
📂 gpkg_contents（コンテンツ目次：featuresやtilesの定義）
📂 gpkg_geometry_columns（ベクタ幾何情報の管理テーブル）
📂 user_vector_features（ユーザーが作成したベクタ属性データ）
📂 user_tile_pyramids（事前生成されたラスタ地図タイル群）

主な特徴と仕様

直接使用が可能
データを一時ファイルにエクスポートしたり、中間変換したりすることなく、APIを介して「.gpkg」ファイル内のデータを直接読み書き・更新できます。異なるGISシステム間でデータモデルの整合性を保ったまま同一の操作結果を得られます。

巨大なサイズ制限とポータビリティ
理論上の最大ファイルサイズは約140TBに達します。ただし、モバイル端末で一般的なFAT32ファイルシステムを利用する場合は、OS側の制限である4GB未満に抑える必要があります。

標準化された幾何エンコーディング
ベクタ幾何形状は、SQL Multimedia (SQL/MM) 規格やSF-SQL規格に基づいて、Point, LineString, Polygon などの標準ジオメトリをバイナリ形式（GeoPackageBinary）でBLOB列に保存します。

強力な拡張性（Extensions）
データベースの高速検索を可能にするために「R*Tree空間インデックス（gpkg_rtree_index）」をサポートするほか、データベーストリガー（Trigger）を仕込むことでデータの更新時に空間インデックスや整合性制約を自動で維持・検証する仕組みが組み込まれています。

3D都市モデルの意味と構造を定義する「CityGML」

スマートシティやデジタルツインの発展に伴い、3次元の空間構造を扱う規格の重要性が高まっています。その中核を担うのがCityGMLです。

「グラフィックス」と「セマンティクス（意味情報）」の融合

COLLADA、KML、X3Dといった一般的な3Dグラフィックフォーマットは、形状（ジオメトリ）とテクスチャ（外観）のビジュアル表現を主な目的としています。これに対しCityGMLは、単なるビジュアル表現に留まらず、都市を構成する建築物、道路、地形、植生、水体などのオブジェクトが「意味的に何であるか（セマンティクス）」、さらに「それらがどう関連し合っているか（関係性・トポロジー）」を記述できるXMLベースのオープンデータモデルです。
これにより、3Dモデルに対して「特定の建物の床面積を算出する」「都市全体の騒音シミュレーションを行う」「災害時の避難経路を予測する」といった、ビジュアルを超えた高度な空間解析・データマイニングが可能になります。

詳細度：LOD（Levels of Detail）

CityGMLでは、データ取得方法や用途に応じた効率的な処理・可視化を行うため、当初はLOD0からLOD4までの5段階の詳細度をサポートしていました。
ただし現行の CityGML 3.0（2021年策定）では、屋内空間を扱う概念が再整理され、従来の「LOD4」が廃止・統合されて LOD0〜LOD3 の4段階へと改定されています。

• LOD0：2.5次元のデジタル地形モデル（DTM）や単純な建物のフットプリント（2D底面）。
• LOD1：建物を単純な箱形で表現する「ブロックモデル」。
• LOD2：屋根の形状（片流れ屋根、切妻屋根など）や外壁構造が判別可能な、より具体的な3Dモデル。
• LOD3：窓やドア、詳細な建築部材の外観、および詳細な地形・植生アセットを反映した実世界に近いモデル。
• LOD4：建物の内部構造（部屋の間仕切り、階段、家具、インドアナビゲーション用の情報）までを精密に網羅したモデル（現行バージョンでは廃止）。

ひとつのCityGMLデータセットの中に、複数のLODモデルを同時に保持することも可能であり、用途に合わせて切り替えて損失なく交換・利用ができます。

テーマ別モジュール構造とADE

CityGMLは機能性・拡張性を担保するためにいくつかの工夫がなされています。

モジュール化（Modularisation）
基本概念を定義する「Core（コア）モジュール」のほかに、建物を定義する「Building」、橋を定義する「Bridge」、トンネルを定義する「Tunnel」、さらに「Transportation（交通）」「Vegetation（植生）」「WaterBody（水体）」など13のテーマ別拡張モジュールが個別に用意されています。システム側は必要なモジュールだけを組み合わせた「プロファイル」を宣言して、部分的に実装することが可能です。

ADE（Application Domain Extension）
CityGMLの標準データモデルを損なうことなく、各学術・産業ドメイン固有の属性情報や新規オブジェクトタイプを安全に追加定義できる「アプリケーションドメイン拡張」の枠組みが用意されています。

次世代の主役：Web API化とクラウドネイティブ標準の台頭

空間データ標準規格は、インターネットの技術スタック（RESTやJSONなど）やクラウドコンピューティングの進化に合わせ、急激なパラダイムシフトを遂げています。

開発者にフレンドリーな「OGC API - Features」

長年使われてきたWFS（Web Feature Service）はXML/GMLベースで記述されており、専門的なGISツール以外でのハンドリングが難しく、一般的なWebフロントエンド開発者にとって導入のハードルが高いものでした。
この反省から誕生した次世代標準がOGC API - Featuresです。OpenAPI仕様（Swaggerなど）をベースに設計されており、一般的なWeb APIと同じ感覚でRESTfulなリクエスト（HTTP GETなど）を通じてデータをJSON（GeoJSON）等で手軽に取得できます。

Part 1 (Core)
基本的なAPI仕様を定義。初期コアは世界測地系であるWGS 84（軸順は経度/緯度）でのデータ取得を前提とした、最も軽量で導入しやすい実装を提供します。

Part 2
WGS 84以外のあらゆる局所的な座標参照システム（CRS）におけるベクタデータの取得およびCRS変換のサポートを拡張定義します。

クラウドネイティブ規格への拡張

近年では、単にAPIを介してやり取りするだけでなく、クラウドのオブジェクトストレージ上で数テラバイトにおよぶ大容量データを直接効率的に管理・ストリーミングするための新しい規格（Cloud-Native Geospatial Standards）の策定・検証がOGC内で強力に進められています。

GeoParquet
列指向のデータ保存形式であるApache Parquetを地理空間データ用に拡張したもので、大規模なベクタデータの属性絞り込みや集計を超高速に行えるフォーマットとしてOGCでインキュベーションされています。

FlatGeobuf
Webブラウザから必要な空間範囲のバイナリ空間ベクタデータをHTTP範囲リクエストを用いて直接、かつ超効率的にストリーミング表示させるための Community Standard 候補として位置づけられています。

GeoZarr
クラウドに最適化された多次元配列データ形式「Zarr」を地理空間データに適用し、気象データや気候モデルなどの多次元データキューブを効率よくエンコーディングする標準規格を策定するため、2024年に新たに「GeoZarr SWG（Standards Working Group）」が発足されました。

国家地図作成機関（NMCA）を巻き込んだ「信頼できるデータシステム（Trusted Data Systems）」

これらのレガシーなWMS/WFSからモダンなOGC APIやクラウドネイティブ標準への移行は、各国の国家地図・地籍機関（NMCA: National Mapping and Cadastral Agencies）にとっても共通の、かつ最優先の課題となっています。
OGCは「Trusted Data Systems Testbed（信頼性の高いデータシステムテストベッド）」プログラムを通じて、レガシーサービスの近代化（WFS/WMSからOGC APIへの移行ガイドラインの作成など）、空間メタデータの標準化、およびデータ連携インフラにおけるセキュリティや信頼性の検証といった実用指向の実験やプロトタイプ開発をスポンサーシップを通じて強力に推進しています。

おわりに：標準規格が切り拓く、これからの位置情報社会

OGCが定義する空間データ標準規格は、異なるプラットフォームやシステム間で「いつでも、どこでも、誰もが」位置情報データにアクセスし、それらを組み合わせて新しい価値を生み出せる相互運用性の基盤です。

「見るだけの地図」から始まったWeb地図は、生データのやり取りを可能にしたWFS/WFS-T、大容量のオフラインポータビリティを実現したGeoPackage、都市全体の意味情報を精緻に保持する3D CityGML、そして現代のRESTfulなWebインフラと高度なクラウドコンピューティングに適応したOGC APIやクラウドネイティブ標準へと、段階的に、しかし劇的に進化を重ねてきました。

スマートシティ、自律走行ロボット、高度な環境シミュレーション、そして防災などの実社会の課題を解決するためには、これらのデータサイロを破壊し、共通の規格を通じてデータを安全かつ正確に繋いでいくことが不可欠です。OGCの活動と標準規格は、まさにこれからの未来の位置情報社会の屋台骨として、今後も重要な役割を果たし続けるでしょう。