Portolanとは何か ― GeoParquet・PMTiles・COG・STACで考えるサーバーレスな地理空間データ基盤

2026年9月2日、Portolan という地理空間データ基盤の仕様とツール群が公開されました。

Portolanが目指しているのは、GeoServerや独自APIを必ず用意して地理空間データを配信する方法ではなく、クラウド向けに最適化したファイルをオブジェクトストレージへ置き、利用者が必要な部分を直接読む構成です。

中心になるのは、次のような既存技術です。

STAC
GeoParquet
PMTiles
Cloud Optimized GeoTIFF（COG）
Parquet
S3互換オブジェクトストレージ

Portolan独自の新しいGISファイル形式を作ったわけではありません。既存のオープンな仕様を組み合わせたうえで、「公開用データをどのような状態まで整えておくか」をかなり具体的に決めています。

この記事では、2026年9月8日時点の公式仕様とCLIドキュメントを確認しながら、Portolanが何を解決しようとしているのか、従来のGeoServerやPostGISを使った構成と何が違うのかを整理します。

Portolanはまだpre-1.0です。仕様やCLIには今後、互換性を壊す変更が入る可能性があります。この記事も2026年9月8日時点の内容として読んでください。

Portolanは何をするものなのか

Portolanの公式リポジトリでは、Portolanを「cloud-native geospatial catalogsのための仕様と、その周辺ツール」と説明しています。

かなり簡単に言えば、次のような構成を標準化しようとしています。

従来のSpatial Data Infrastructure（SDI）では、データを公開するためにサーバーやデータベース、APIを用意する構成が一般的でした。

たとえば、次のような構成です。

Portolanでは、公開用データそのものをネットワーク越しに効率よく読める形式へ変えておきます。

ここでいう「serverless」は、インターネット上にサーバーが一台も存在しない、という意味ではありません。S3などのストレージサービスは当然使います。

ポイントは、データを読むたびに専用の地図サーバーや独自APIを通さなくてもよいことです。

Portolanの仕様にも、Portolan Catalogはstatic catalogであり、STAC APIのような「Portolan API」を実装するものではない、と明記されています。

Portolanは新しいGISフォーマットではない

Portolanを調べ始めたときに、最初に整理しておいた方がよい点です。

Portolanという拡張子のファイルを作るわけではありません。

中核になる形式は、すでにGISやCloud Native Geospatialの分野で使われているものです。

用途	主な形式・仕様	Portolanでの役割
カタログ	STAC 1.1.0	データの構成、メタデータ、リンクを管理
ベクタ解析	GeoParquet	属性・形状を直接検索、集計するためのデータ
Web地図表示	PMTiles	ベクタタイルを静的ファイルとして配信
ラスタ	COG	DEM、衛星画像、解析結果などの部分読込み
非空間表	Parquet	表形式データの公開
保存先	S3互換ストレージなど	データとSTACを静的ファイルとして公開

Portolanの意味は、単にこれらの形式を使うことではありません。

実際にネットワーク越しで効率よく使える状態まで整えるための要件を追加しているところに特徴があります。

なぜGeoParquetとPMTilesを両方使うのか

Portolanのベクタデータでは、GeoParquetとPMTilesを組み合わせる考え方が採られています。

同じ地理空間データでも、解析と地図表示では求められる性質が違うためです。

GeoParquetは解析側

GeoParquetは、Parquetに地理空間情報を持たせた形式です。

DuckDBやPythonなどから必要な列や行だけを読みやすく、大規模データの検索や集計と相性があります。

たとえば、日本全国の1kmメッシュをGeoParquetで公開しておけば、利用者側ではDuckDBなどを使って必要な条件だけ抽出できます。

概念的には次のような使い方です。

SELECT
    mesh_code,
    population
FROM read_parquet('https://example.jp/mesh/japan_1km.parquet')
WHERE population >= 10000;

PortolanがDuckDB専用という意味ではありません。GeoParquetを公開しておくことで、利用者が自分の使いやすい処理系を選べる、という考え方です。

PMTilesは表示側

PMTilesは、地図タイルを一つのファイルとして扱える形式です。

HTTP Range Requestを使い、地図表示に必要な範囲だけを取得できます。そのため、動的にタイルを生成するサーバーを常時動かさなくてもWeb地図を構成できます。

Portolanの現行仕様では、PMTilesはベクタデータの可視化用派生データとして推奨されており、PMTilesを提供する場合はMapLibre GL Style形式のスタイルも要求されています。

整理すると、次のような役割分担になります。

GeoParquet = 検索・集計・解析
PMTiles    = Web地図での高速表示

この分け方は、全国規模のベクタデータを扱う場合にはかなり分かりやすいと思います。

GeoParquetなら何でもよいわけではない

Portolanで興味深いのは、ファイル形式だけで合否を決めていないところです。

現行仕様では、GeoParquetについて次のような条件が定められています。

GeoParquet 1.1または2.0を使用する
行を空間的に並べる
Row Group単位で空間範囲を判断できる統計情報を持たせる
Row Groupを150,000行以下にする
列構成はSTACのtable extensionで文書化することが推奨される

たとえば、同じ地域の地物がファイル内でばらばらに配置されていると、狭い範囲を検索するだけでも多くのRow Groupを読む必要があります。

空間的に近い地物を近くへ並べておけば、検索対象と関係のないRow Groupを読み飛ばしやすくなります。

空間順序なし

北海道
静岡
沖縄
北海道
九州
静岡
...

        ↓

狭い範囲を検索しても
多くのRow Groupを確認する必要がある

空間順序あり

北海道
北海道
東北
関東
中部
近畿
...

        ↓

Bounding Boxと統計情報を使って
不要なRow Groupを読み飛ばしやすい

「GeoParquetへ変換できたので終わり」ではなく、配信用データとして検索性能が出る状態まで確認する、というのがPortolanの考え方です。

ラスタはCOGを使う

DEM、航空写真、衛星画像、浸水深などのラスタデータには、Cloud Optimized GeoTIFF（COG）を使います。

COGは通常のGeoTIFFと同じTIFF系の形式ですが、HTTP Range Requestによる部分読込みを考慮した内部構造を持っています。

たとえば100GBのラスタがあっても、地図に表示している範囲と解像度に必要なデータだけを取得できます。

Portolanでは、単にCOGとして認識できるだけでは足りません。

現行仕様では、たとえば次の項目まで要求されています。

OGCのCloud Optimized GeoTIFF要件に適合すること
適切な内部タイルを持つこと
必要なOverviewを持つこと
各バンドにminimum / maximum / mean / standard deviationの統計値を埋め込むこと

特にOverviewは、広域表示時に高解像度データを大量に読まないために重要です。

これもGeoParquetと同じで、「COGという名前のファイルになっているか」より、実際の利用時に部分読込みが機能するかを重視した設計です。

STACがカタログの骨格になる

Portolanの中心にあるのはSTAC 1.1.0です。

Portolan Catalogは、STAC Catalogをベースにした静的なファイル構成になっています。

最小構成を単純化すると、次のような形です。

catalog.json
README.md
AGENTS.md

boundaries/
    collection.json
    README.md
    AGENTS.md
    boundaries.parquet
    boundaries.pmtiles
    styles/
        default.json

catalog.jsonやcollection.jsonは機械が読むための情報です。

一方で、PortolanではREADME.mdとAGENTS.mdも重視しています。

ファイル	主な対象
`catalog.json` / `collection.json`	GISソフト、プログラム、カタログツール
`README.md`	人が内容を確認するときの説明
`AGENTS.md`	AI Agentがデータを利用するときの案内

Portolanの現行仕様では、root catalogとsubcatalogにはcatalog.json、README.md、AGENTS.mdが必要で、collectionにもcollection.json、README.md、AGENTS.mdが必要です。

データを公開したものの、列名の意味や利用条件が分からない、という状況を避けるために、データ本体と説明を同じカタログの中で管理します。

AI Agentを最初から利用者として考えている

Portolanが最近のデータ基盤らしいと感じるのは、人だけでなくAI Agentも利用者として想定している点です。

公式仕様では、Portolan Catalogは人間とAgentの両方が使いやすいことを目標にしています。

そのため、STACによる構造化メタデータだけでなく、AGENTS.mdやAgent向けのskillも用意されています。

たとえば、データ公開側で次のような情報を整理できます。

データの意味
列の意味
座標系
時間範囲
ライセンス
作成元
既知の制約
推奨する利用方法
関連データ

これによってAgentは、ポータルサイトごとの画面操作やAPI仕様を個別に覚えるのではなく、STACとドキュメントをたどってデータを探せるようになります。

ただし、Portolan自体がLLMを内蔵しているわけではありません。

Portolanは、人やAgentが扱いやすい状態で地理空間データを公開するための基盤です。

HTTP Range RequestとCORSも仕様に入っている

クラウド向けファイルを作っても、公開先のHTTP設定が悪ければ部分読込みは機能しません。

この点もPortolanでは仕様に含まれています。

現行仕様では、Portolan自身が管理するcloud-native assetの配信先に対して、少なくとも次のような条件があります。

HTTP Range Requestを処理できる
206 Partial Contentを返せる
Accept-Ranges: bytesを提供する
HEADで正しいContent-Lengthを返す
ブラウザから利用できるCORS設定を行う
Rangeなど必要なリクエストヘッダーを許可する
Content-RangeやETagなど必要なレスポンスヘッダーを公開する

つまり、

GeoParquetを作った
        ↓
S3へ置いた
        ↓
完成

ではありません。

GeoParquet / PMTiles / COG
        ↓
Range Request対応
        ↓
CORS対応
        ↓
ブラウザや解析ツールから部分読込み

までを公開品質として考えます。

これは実際にCloud Native GISを運用するときには重要な部分です。

rashidでカタログを検査する

PortolanにはrashidというValidatorがあります。

Portolan仕様への適合は、単にstac_extensionsへPortolanのURIを書けばよいわけではありません。

公式仕様では、Validatorを通ることがconformanceの条件になっています。

rashidは、主に次のような検査を行います。

STAC構造
Portolan固有のメタデータ要件
GeoParquetの空間順序
Row Group統計
COG内部統計
ファイルサイズやchecksum
公開先のRange Request
公開先のCORS

インストール例は次のとおりです。

uv tool install rashid

カタログの確認は、たとえば次のように行います。

rashid check ./my-catalog

公開後のHTTP RangeやCORSまで確認する場合は、--liveを使う方法も用意されています。

rashid check ./my-catalog \
  --live \
  --live-base-url https://data.example.jp/my-catalog/

Cloud Native形式を名乗っていても、実際には必要な統計や配信設定が不足していることがあります。Portolanでは、その部分をValidatorで機械的に確認できるようにしています。

Portolan CLI

カタログの作成や管理にはportolan-cliが用意されています。

2026年9月8日時点ではpre-1.0で、公式ドキュメントにもbreaking changeの可能性があると明記されています。

推奨されているインストール方法の一つはuvです。

uv tool install portolan-cli

基本的な流れは、Gitに少し似ています。

カタログを作る

mkdir my-catalog
cd my-catalog

portolan init

データを登録する

portolan add data/

チェックする

portolan check

--fixを付けることで、変換可能なデータをcloud-native形式へ直す処理も用意されています。

portolan check --fix

CLIのドキュメントでは、Shapefile、GeoJSON、GeoPackageなどのベクタをGeoParquetへ、GeoTIFFやJPEG2000などのラスタをCOGへ変換する流れが説明されています。

公開する

S3などへ公開する場合はpushを使います。

portolan push s3://my-bucket/my-catalog

ほかにも、現在のCLIには次のようなコマンドがあります。

portolan init
portolan scan
portolan add
portolan add-external
portolan check
portolan info
portolan list
portolan push
portolan pull
portolan sync
portolan clone
portolan metadata
portolan readme
portolan version

実際の引数や挙動はまだ変わる可能性があるため、利用時には公式CLI Referenceを確認した方が安全です。

VersionとChecksumも管理できる

Portolan CLIにはcollection単位のversion管理があります。

portolan version current boundaries
portolan version list boundaries
portolan version bump boundaries 1.1.0
portolan version rollback boundaries

CLIの説明では、デフォルトの仕組みでcollectionのversionとchecksumをデータベースなしで追跡できるとされています。

公開データでは、同じファイル名のデータがいつの間にか更新されてしまうと、解析結果を再現できなくなります。

2026-04版
    ↓
2026-07版
    ↓
2026-09版

といった更新履歴を追える仕組みは、行政データや防災データにも使いやすそうです。

なお、Portolan仕様そのもののversionと、各datasetのversionは別物です。現行仕様でも混同しないよう明記されています。

Portolan Registryはデータ本体を集める場所ではない

PortolanにはRegistryという仕組みがあります。

ここで面白いのは、すべてのデータを中央サーバーへ集める構成ではないことです。

Registryは、独立して公開されているCatalogを見つけるための入口です。

公式の紹介記事では、Registryに登録されても元データのbytesは公開者のstorageから移動せず、利用者は元の公開先へ直接アクセスすると説明されています。

そのためRegistry自体がなくなっても、個々のCatalogとデータはそのまま利用できます。

中央集権的な巨大データベースを作るのではなく、分散したCatalogを共通のルールで発見できるようにする考え方です。

GeoServerやPostGISは不要になるのか

Portolanを見ていると、GeoServerやPostGISが全部不要になるようにも見えます。

実際には、用途を分けて考えた方がよいと思います。

Portolanが向いている処理

公開
配布
参照
ダウンロード
部分読込み
静的Web地図
大規模データの直接解析
データカタログ

こうした処理では、GeoParquet、PMTiles、COG、STACとオブジェクトストレージだけで済む場面が増えます。

PostGISやAPIが必要になる処理

複数ユーザーによる編集
トランザクション
業務システムからの更新
複雑な権限管理
サーバー側の業務ロジック
解析ジョブの実行
シミュレーション実行
状態を持つ処理

こうした用途では、データベースやAPI、Workerなどが引き続き必要です。

Portolanの公式FAQでも、2026年9月時点ではtransactional editingは未対応で、access-controlled dataはv1.0に向けて計画中とされています。

したがって、

Portolan vs PostGIS

という二者択一ではなく、

という住み分けの方が現実的です。

全国1kmメッシュのようなデータにも使えそう

たとえば、日本全国1kmメッシュと防災データを公開するとします。

Portolanを使わない場合でも、GeoParquetとPMTilesを使えばかなりシンプルな構成を作れます。

e-Stat等の元データ
        ↓
   GeoParquet
      ├── DuckDB
      └── PMTiles
             ↓
         Web GIS

ここへPortolanの考え方を加えると、データ本体だけでなく公開時の情報も揃えられます。

japan-disaster/
├── catalog.json
├── README.md
├── AGENTS.md
│
├── mesh/
│   ├── collection.json
│   ├── README.md
│   ├── AGENTS.md
│   ├── japan_1km.parquet
│   ├── japan_1km.pmtiles
│   └── styles/
│
├── flood/
│   ├── collection.json
│   ├── flood.parquet
│   └── flood.pmtiles
│
└── dem/
    ├── collection.json
    └── dem.tif

この構成なら、

解析    → GeoParquet / COG
表示    → PMTiles / COG
発見    → STAC
説明    → README.md
Agent   → AGENTS.md
検査    → rashid
公開    → S3互換Object Storage

と役割を分けられます。

データ公開基盤として見たときに、Portolanが一つ新しいソフトウェアを追加するというより、GeoParquetやPMTilesで作ったデータを、どう整理し、検査し、公開するかというルールを追加すると考えた方が理解しやすいです。

防災データ基盤との相性

防災分野では、データの種類がかなり多くなります。

たとえば、

行政界
人口
建物
道路
河川
DEM
洪水浸水想定区域
土砂災害警戒区域
避難所
降雨
衛星画像
解析結果

などです。

これらを一つのデータベース設計へ無理に押し込むより、公開用データを用途に合ったcloud-native形式へ整理し、STACで横断的に管理する方法には利点があります。

特に、元データの管理やシミュレーションは別システムで行い、公開・共有する段階でPortolan Catalogへ変換する構成は組みやすそうです。

ただし、リアルタイム観測値を秒単位で更新したり、ユーザーがデータを編集したりするシステムについては、Portolanだけで完結させるものではありません。

現時点で気を付けたいところ

Portolanは興味深い取り組みですが、2026年9月8日時点ではまだ初期段階です。

公式仕様のCHANGELOGでは、現在の仕様versionとして**0.2.0（2026年8月28日）**が記録されています。また公式サイトでも、短期的にはbreaking changeがあり得るためearly adopter向けと説明されています。

現時点で特に気を付けたいのは次の点です。

仕様がpre-1.0である
CLIもpre-1.0である
breaking changeの可能性がある
access-controlled dataはまだ今後の対応
transactional editingは未対応
公開先にはRange RequestとCORSの適切な設定が必要
Portolanへ適合させるには、形式変換だけでなくメタデータや品質検査も必要

COPCとGeoZarrについて

ここは公式情報の記載に少し差があります。

PortolanのリポジトリREADMEやCLIではCOPCやGeoZarrが扱われています。一方、2026年9月時点の公式FAQでは、ZarrやCOPCについて「normative support」の不足を現時点のgapとして挙げています。また、現在のformats.mdではGeoZarrを将来候補として扱う記述があります。

仕様が動いている時期でもあるため、この記事ではGeoParquet・PMTiles・COG・Parquetを現在の中核として扱い、COPCやGeoZarrは成熟状況を確認しながら採用するものとして整理しました。

このような差があること自体、今は仕様を固定的に見るより、公式CHANGELOGとValidatorを確認しながら使う段階だと考えた方がよさそうです。

Portolanをどう見るか

Portolanを最初に見たときは、「STACとGeoParquetとPMTilesを組み合わせただけでは」と感じるかもしれません。

実際、使っている技術の多くは既存のものです。

ただ、地理空間データを公開するときには、形式を選ぶだけでは解決しない問題があります。

GeoParquetにはしたが空間順序が悪い
COGだがOverviewがない
PMTilesはあるがstyleが分からない
CORSが設定されていない
ライセンスが分からない
元データの出典をたどれない
列名の意味が分からない
更新versionが分からない

Portolanは、このあたりを「公開者ごとの工夫」で終わらせず、一定の品質基準として揃えようとしています。

個人的には、新しいGISサーバーの代替製品というより、

Cloud Native Geospatialでデータを公開するときの実践的なパッケージング規約

として見ると分かりやすいと思います。

GeoParquet、PMTiles、COGをすでに使っている環境であれば、既存構成を捨てる必要はありません。

その上に、

STAC
README
AGENTS.md
Version
Checksum
Validator
Registry

を加えて、公開品質を揃えるために使う方法が現実的です。

まとめ

Portolanは、地理空間データをクラウド向けファイルとして公開するための仕様とツール群です。

中心となる考え方はシンプルです。

データをAPIの奥に閉じ込める
        ↓
必要な部分を直接読めるファイルとして公開する

そのために、GeoParquet、PMTiles、COG、STACなど既存のオープン仕様を組み合わせ、さらに空間順序、統計情報、Overview、CORS、Range Request、ドキュメント、出典、Validatorまで含めて公開品質を定義しています。

一方で、まだpre-1.0であり、トランザクション編集やアクセス制御など、従来型の業務GISが持つ機能をすべて置き換えるものではありません。

現時点では、まず次のようなデータから試すのがよさそうです。

行政界
統計メッシュ
公開防災GIS
DEM
衛星画像
浸水想定区域
解析結果

特に、すでにGeoParquet + PMTiles + COGを使った静的公開を考えている場合、Portolanの仕様はその構成を一段整理する材料になります。

今後仕様が安定していけば、自治体、研究機関、企業がそれぞれの場所で公開している地理空間データを、共通の方法で発見し、そのままGISや解析環境、Agentから利用する仕組みとして面白い位置に来ると思います。

参考リンク

この記事では、できるだけPortolan公式の情報を参照しました。