🦆

DuckDB と GDAL の GeoParquet を巡るニワトリ(アヒル?)卵問題

2025/02/03に公開

GDAL のレポジトリに「DuckDB integration?」という issue が立てられています。議論を追ってみたらややこしかったので、あとで見返すためにメモります。

https://github.com/OSGeo/gdal/issues/10887

概要

モチベーションとしては、GDAL はすでに GeoParquet を扱えますが、それに使われている Apache Arrow の C++ 実装よりも DuckDB の方が速いのでそっちを使いたい、ということのようです。

ただ、ちょっと事情がややこしいのは、DuckDB 側にも spatial extension というものがあり、それが GDAL を使っている、という点です。spatial extension は GDAL を静的リンクしているので、異なるバージョンの GDAL が混在して予期しない挙動を引き起こす可能性があります。

spatial extension 側でも、GDAL の機能を別に切り離そうとしたことがあるようですが、この issue は実現されないまま閉じられています。たしか、GeoParquet を効率的に読むには GIS 的な計算が必要(空間インデックスとか WKB のパースとか?)で、読み書きの機能だけ切り離そうと思っても難しい、みたいなことだったような気がします。

https://github.com/duckdb/duckdb-spatial/issues/15

提案されている方針

ではどうするか、というと、spatial extension の開発者(DuckDB の人)のコメントで2つの方向性が示されています。

  1. spatial extension を無視して Parquet の読み書きのためだけに DuckDB を使う
  2. spatial extension から GDAL に依存する部分を取り除いて、GDAL の DuckDB driver を介して GIS 的な操作を提供する(?)

ここで、1. は上に書いたように spatial extension は GDAL に深く依存しているので難しいようです。GeoParquet の読み書きだけやるミニ版 spatial extension をつくればいけるかも?、ともコメントされています。

一方の 2. は、かなり根本的な変更なので見通しが立たないものの、DuckDB 側としても様々な理由から GDAL へ直接依存するのをやめたいと思っていて、できればやりたいね、という感触のようです。

ADBC

その後、ADBC(Apache Arrow のデータベースコネクタ)のドライバが開発されて、GDAL の v3.11 に入るようです。「GDAL で GeoParquet を速く処理したい」というときはこれ経由で DuckDB を使う、というのがいったんの結論になりそうです。

https://github.com/OSGeo/gdal/pull/11003
https://github.com/OSGeo/gdal/pull/11459

ちなみに、あまりよくわかってないんですが ADBC 側でネイティブに GeoArrow をサポートする?という話もあり、これはまだ実装されてないみたいです。たぶん実装されてないから GDAL 側でなんとかしてるのかな?

https://github.com/apache/arrow-adbc/issues/2098

あと R ユーザーに良いニュースとしては、このバージョンの GDAL が使えるようになると、R でも GeoParquet を読めるようになるっぽいです。

https://github.com/OSGeo/gdal/pull/11003#discussion_r1804090505

Discussion