FOSS4GとCloud Nativeについて
0. この記事について
本記事は日本測量協会の専門誌、月刊誌『測量』の2022年9月号の「ちょっと気になる技術」に寄稿した内容をベースにWeb用に書き直したものとなります。
1. はじめに
OSGeo財団並びにOSGeo財団日本支部(OSGeo.JP)ではFOSS4G(Free OpenSource Software For Geospatial)の支援をベースに活動をしております。
今回はFOSS4Gとその関連技術としてCloud Nativeという概念についてご紹介します。
2. FOSS4Gについて
FOSS4Gは地理空間情報を扱う様々なオープンソースのツールやライブラリを扱う言葉となります。
そのため、OSGeo財団の支援を直接受けていないものも含めてFOSS4Gというくくりで扱っています。
代表的なツールやライブラリについて、簡単に説明します。
GDAL/OGR: GDALはラスタ形式のファイルを、OGRはベクタ形式のファイルを扱うツール及びライブラリです。パッケージとしてはGDALとして配布されていますが、扱う形式によってプログラム名がGDALのものかOGRのものかが分かれます。
Proj: 主の座標系を扱うツール及びライブラリです。例えば、ベクタ形式のファイルで旧日本測地系から世界測地系などへの変換を行う際にはOGRのコマンドが内部的にProjの仕組みを使って変換をします。また、Projは移植性が高く、JavaScriptなどでも扱うことができます。
GEOS: GEOSはGISで使われるアルゴリズムを重点に置いたライブラリです。GEOS自体はGDALなどの中核として機能します。
PostGIS: PostgreSQLデータベースに地理空間情報を扱う仕組みを実装した拡張ライブラリです。この仕組みによって地理空間情報を簡単にデータベースで扱うことができ、空間クエリを使う事で、例えば「現在地から1キロ以内の地物を検索する」などがSQL文で簡単に記述することが可能となります。
QGIS: Qtで書かれたGISアプリケーションです。内部的にGEOS, GDAL, Projなど上記に上げたライブラリに依存していて、一部の機能はGDALなどのコマンドのラッパーとして動作します。
読者の皆様もQGISに触れたことはある、もしくは聞いたことがあると思います。QGISはFOSS4Gのツールやライブラリの集合体のようなものだと考えていただければと思います。
3. Cloud Nativeとは何か
FOSS4Gの世界では様々なフォーマットを利用することができます。例えばベクタ形式であれば、Shapefileに代表されるようなプロプライエタリな形式からGeoPackageに代表されるようなオープンな形式まで扱うことができます。
その中で、最近話題となっているのがCloud Nativeという仕組みに対応したフォーマットになります。
では、Cloud Nativeとはどういう概念なのでしょうか?
まず、今まで扱われていたフォーマットを例に扱います。
図1を参照してください。
図1: 一般のフォーマット
一般的なフォーマットでは、ヘッダー部分とデータ部分に分かれます。この場合では、データ部分を全て読み込まないと画面上に表示ができないという問題が発生します。
これの何が問題かがわかりづらいかと思いますが、例えばウェブブラウザ上で大きなファイルを読み込みたい場合、ファイル全体のダウンロードが必要になるため、読み込みに時間がかかり、またメモリへの負担も大きくなります。
また、解像度によっては表示する必要の無い領域などがあります。
これらの問題を解決するために図2のような「タイル化」というものを実施していました。
図2: タイル(国土地理院から引用)
しかしながら、「タイル化」というのも問題があります。例えば、ウェブサーバにタイルをそのままホストする場合、ファイルの数が膨大になるケースがあるため、オペレーションシステムによってはサーバのチューニングをしない限りホスティングに支障がでるケースなどがあげられます。
また、「タイル化」は比較的コストが高い作業になります。
そこでCloud Nativeという技術が最近の流行として出てきました。
Cloud Nativeではデータを細かく分割しています。
そしてHTTP GET Rangeメソッドを用いて部分的にデータを取得することで、巨大なファイルをウェブサイト上に置いてもユーザにとっては全体をダウンロードする必要なく閲覧が可能になります(図3)。
図3: Cloud Native概要
Cloud Nativeに対応したフォーマットをホスティングするためにはサーバはHTTP Get Rangeメソッドに対応をしている必要があります。ただし、現在普及している一般的なサーバではほとんど対応しているため、無効になっているかどうかを確認する程度で良いはずです。
4. Cloud Native対応フォーマット
では、最後にCloud Nativeに対応したフォーマットをご紹介します。
FlatGeoBuf: FlatGeoBufは単一レイヤーのベクタ形式のためのフォーマットです。単一レイヤーのため、単純にShapefileからの置き換えとして利用することが可能です。GDAL3.1及びQGIS 3.16からサポートされており、公式サイトではLeaflet及びOpenLayersのサンプルが紹介されています(図4)。
図4: FlatGeoBufの表示
Cloud Native GeoTiff(COG): GeoTiffファイルをCloud Nativeに対応させたフォーマットとなります。通常のGeoTiffファイルとも互換性があるため、COGに対応していないアプリケーションでも利用が可能です。もちろん、QGISからも操作が可能です。
Cloud Optimized Point Cloud(COPC): Point Cloud(点群)のフォーマットであるLAZ(LASZip)を拡張したもので、EPT data formatからの新たに派生したファイルとなります。EPTとは違い、補助的なjsonファイルが不要となり、一ファイルでホスティングできるようになっています。
Potree v2 format: Point Cloudをウェブ上で閲覧するためのプログラム、Potreeもバージョン2からCloud Nativeの発想を取り入れています。バージョン1ではタイル化に近いフォーマットであったところを、バージョン2ではHTTP Get Rangeメソッドを使った実装になり、必要なファイルが4ファイルと少なくなったのが特徴です。
PMTiles: Protomaps社によって作成されたCloud Native形式でタイルを配信する仕組み。MBTilesと似ているが、MBTilesはSQLiteをベースに作られたのに比べ、PMTilesはHTTPで配信することにフォーカスをしているという点が大きく異なる。また、MBTilesからPMTilesへの変換はCLIで簡単に処理が可能。
5. 最後に
今回紹介したツール及びフォーマットは全てオープンソースで作られているものです。オープンソースを地理空間情報で活用していくことは今後重要なスキルとなるのではないでしょうか。
Discussion