デジタルアーカイブでも必要になる、可搬的なタイル画像フォーマット
ラスタ地図データではもう当たり前になったタイル技術。私がMaplatの開発を始めた頃から欲しかった「可搬な単一ファイルからレンジリクエストで部分だけ取り出す仕様」も、いつのまにかCOGやPMTiles、RaQuetなどの登場によって、今や「普通のこと」として扱われるようになりました。
個人的には古地図を扱う関係上、文化財データの動向にも興味があるのですが、そちらでは高精細画像を配信する仕様としてIIIFが提唱されています。これはファイル仕様というよりAPI仕様なのですが、動的サーバが用意できない環境でも運用できるよう「静的ファイルでの配置」も考慮されており、その場合はWMTSなどの地図タイルサーバとほぼ相互運用が可能です。実際、OpenLayersにはIIIFを読み込めるデータソースも定義されています。
また文化財らしく、多くのメタデータを「マニフェスト」として提供できたり、逆にマニフェストと紐づいた多数の画像を同一文化財エンティティの構成物（例えば、多数のページを含む古文書など）として管理できたりする点も、非常に優れた仕様です。
しかし、個人的にずっと気になっていたのは、この優れたAPI仕様を満たしつつ「可搬的に運用できる共通フォーマット」が、管見の限りでは存在しないことでした。
山中湖情報創造館の丸山高広さんも以前からこの点を問題視されていましたが、APIが統一されていても、ベンダーごとのシステム内部でのデータの持ち方はバラバラです。そのため、予算が尽きたりベンダーのサポートが停止したりすると、途端にアーカイブへのアクセスが困難になってしまいます。
もし、可搬的なデータ構造さえあれば、システムがなくなってもデータそのものは移管できます。それが統一フォーマットであれば他システムでの再現も容易ですし、「1エンティティ1ファイル」に固められた形式なら、取り扱いもぐっと楽になります。
地図データの世界ではCOGをはじめとするクラウド最適化フォーマットが一般的になった今、その技術を流用して、地図データと文化財アーカイブデータの両方で使える共通ファイルフォーマットが作れないだろうか、と考いうことをえていました。
あとはついでなのですが、文化財的な古地図を「地図」として配信する私のMaplatでも、そんな共通仕様があれば乗っかれるので便利だな、という個人的な期待もありました。
文化財ファイルデータに必要な仕様洗い出しと最適な技術の検討
とはいえ、やはり地図データと文化財データではユースケースの違いがあるのは事実です。
どのような違いがあるか、それを元に、複数の地図フォーマットのうち何が文化財データには向いているか、少し整理してみました。
1. 座標系はピクセル座標
多くの場合、地図画像の座標系はWebメルカトル（EPSG:3857）ですが、文化財画像の場合は画像そのものの「ピクセル座標」が基準です。
座標系としてWebメルカトルを使いつつ、タイル構造だけを流用する手もありますが、やはりデータの本質としてしっくりこないものがあります。
幸い、最近は座標系設定を柔軟に埋め込めるTMS 2.0 (OGC Two-Dimensional Tile Matrix Set 2.0)仕様が提供されており、これをCOGやPMTilesのメタデータ領域に埋め込むことで、自由な座標系を利用できるようになっています。
例えば、実質的にピクセル座標と一致するような座標系を設定し、PNGをCOGに変換するには、以下のようなgdal_translateコマンドが有効なようです。
> gdal_translate -a_srs "PROJCRS[\"unknown\",BASEGEOGCRS[\"unknown\",DATUM[\"unknown\",ELLIPSOID[\"unknown\",6378137,0,LENGTHUNIT[\"metre\",1]]],PRIMEM[\"Greenwich\",0,ANGLEUNIT[\"degree\",0.0174532925199433]]],CONVERSION[\"unknown\",METHOD[\"Orthographic\"],PARAMETER[\"Latitude of natural origin\",0],PARAMETER[\"Longitude of natural origin\",0],PARAMETER[\"False easting\",0],PARAMETER[\"False northing\",0]],CS[Cartesian,2],AXIS[\"(E)\",east,ORDER[1]],AXIS[\"(N)\",north,ORDER[2]],LENGTHUNIT[\"metre\",1]]" -of COG -co COMPRESS=JPEG original.png id_cog.tif
これで、ピクセル単位と一致する座標系（ただし、左上が[0,0]で、右下方向に[x, -y]となる「数学的に平坦な」座標系）が埋め込まれたCOGを作成できます。もし、もっと素直に「ピクセル座標」として定義される座標系を埋め込むスマートな方法をご存じの方がいれば、ぜひ教えていただきたいところです。
2. 複数の画像が単独エンティティとなることがある
先ほども触れた古文書の各ページのように、複数の画像を一つの塊として扱うことが必要な場合もあります。
これを収納するのに、COG（すなわちTIFF）のマルチページ仕様はうってつけです。他の仕様でも原理的には可能ですが、「古くから枯れた仕様」として複数画像を標準的に扱えるのは、アーカイブ用途としては大きな強みだと思えます。
ただ、このTIFFの複数画像格納仕様には、特有の弱みもあるのですが、それについては後述します。
3. デフォルトで画像として機能してほしい
地図を扱う人であれば、専用のAPIやGISソフトで閲覧することが多いため、データファイルそのものが即座に画像として機能しなくても、あまり気にしないかもしれません。
しかし、文化財を扱う現場では、必ずしも非技術者が専用ソフトを常用しているとは限りません。むしろ、「ファイルそのものを直接開いて情報を得たい」というニーズは非常に強いと感じます。
PMTilesやRaQuetのような、それ単体では画像として表示できない「コンテナ」的な仕様は、文化財関係者には少しとっつきにくく感じられるかもしれません。
その点、COGはあくまでTIFFファイルです。普通のペイントソフトでも1枚目は見られますし、マルチページTIFF対応のビューアーなら複数枚の画像も全て確認できます。「そのまま画像として見られる」という点は、文化財を扱う上での親和性が非常に高いです。
4. IIIF（やMaplat）のメタデータを同梱できる必要がある
地図は「どこにあるか（投影系）」の情報があれば十分なことが多いですが、文化財データはIIIFのマニフェストのような、より複雑で膨大な付随情報を一緒に持ち運ぶ必要があります。Maplatにおいても、非線形な座標変換情報（GCPや歪み情報）を管理しなければならず、事情は同じです。
COGには独自のメタ情報タグを入れる領域があるため、そこにJSONなどを組み込めば、データと一緒に配布できます。
こうした総合的な視点から考えると、ラスタ地図データと文化財データを共通化する基礎として、COGはかなり有力な候補として先んじているのではないかと考えました。
MPack（仮称）の提案
1. どうせならメタデータもクラウド最適化したい
確かにCOGのヘッダ領域にJSONなどを埋め込むことはできますが、メタデータの量が増えてくると、その中から特定の情報を探すための「ランダムアクセス性」が低くなってしまいます。
せっかく画像がタイル化されて高速にアクセスできるのであれば、メタデータ側も「検索可能性」を高め、クラウド最適化したいところです。
そこで、COGの末尾に、DuckDBのような「クラウド最適化された検索可能なフォーマット」をそのままくっつけてしまえばいいのではないか、というアイデアに至りました。
この構想を、今回相談に乗ってくれたGemini（生成AI）は「MPack」と名付けてくれました。将来もっと良い名前が出るかもしれませんが、響きが良いので今はこれで呼ぶことにします。
2. 仕組みの説明
基本的な考え方は非常にシンプルです。
- タイル化された各ズーム画像やCRS情報などは、既存のCOG仕様をそのまま踏襲します。
- COGデータの後に、DuckDBファイルをバイナリとしてそのまま連結します。
- ファイルの末尾に「DuckDBの開始位置」と「サイズ」を記録した数バイトのトレーラー（フッター）を付けます。
読み込み側では、まず末尾数バイトを読んでDuckDBの場所を特定し、その範囲をDuckDB-Wasmなどで扱います。一方で、前半部分はGeoTIFF APIで画像として扱います。
こうすることで、「複数画像に対応したタイル画像」と「柔軟で高速検索可能なメタデータ」を、一つのファイル内で、かつどちらもRange Request（部分取得）で扱えるようになります。ここにIIIFやMaplatの情報を入れれば、単独ファイルとして可搬でありながら、そのままアーカイブシステムの高速なデータストアとして機能するわけです。
3. 簡単なPoC
実際に動くものがないと始まらないので、簡単なPoCを作成しました。
MPack PoC デモサイト
- 1024x1024のフラクタル画像を、ピクセル座標系のCOGとして作成。
- その後ろに、データ名やソースURLなどを格納したDuckDBを連結。
- OpenLayersでCOG部分からタイルを表示しつつ、DuckDB-Wasmで同じファイル内のDB領域から直接メタデータを取得。
このデモにより、単一の静的ファイルから、画像とDBの双方に対して個別にRange Requestを投げ、共存させられることが証明できました。
4. COGの弱点も克服できる可能性
ここで、先ほど触れたTIFFの複数画像格納の弱点について。
TIFFのマルチページ仕様は「連結リスト（リンク）」構造になっています。つまり、100ページ目にアクセスしたければ、1ページ目から順にメタデータを辿らなければなりません。これはクラウド越しに特定のページを開く際、非常に効率が悪いです。
しかし、もしDuckDB部分に「各ページが何バイト目にあるか」というインデックス（スーパー目次）を持たせておけばどうでしょうか。
SQLでインデックス値を一瞬で取得し、TIFFの鎖を無視して特定ページへランダムアクセスする、という使い方が可能になります。COGの伝統的な弱点を、DuckDBが補完する構造にできるのです。
まとめ
今回の検証を通じて、COGとDuckDBを繋げるというアプローチが、ラスタ地図、IIIFアーカイブ、そしてMaplatという異なる領域を横断する「可搬データフォーマット」として、高いポテンシャルを持っていることが分かりました。
メタデータ部分は必ずしもDuckDBである必要はなく、ParquetやZarrといった他のフォーマットでも面白いかもしれません。このフォーマットにした方がよいのでは？みたいなアイデアは、ぜひ教えていただきたいです。しかし、「用途別にクラウド最適化されたフォーマットを単純接続し、単一のURLで管理する」 という考え方は、サーバーレスなアーカイブの未来に向けた、一つの確かな手応えとなりました。
やりたいことは、これで概ね実現できそうです。まずはこの構成をベースに、より実戦的なデータ管理のあり方を深掘りしていきたいと思っています。