オンラインデータに望まれる形式がバイナリベクトルタイルなのか議論する

背景　〜Shapefile に関する議論をきっかけに〜

そもそも、バイナリベクトルタイル（ここでは vector-tile-spec 準拠データ）の方言について https://github.com/hfu/ruby-mvt を使って確認していた時に、バイナリベクトルタイルに方言があるとするならば、 Shapefile にもたくさん方言があった。という話から始まる。
Shapefile はほとんど使わなくなったというプレイヤーと、今でもよく使っているというプレイヤーがある。
Shapefile が衰退した後を何が埋めるか。Shapefile はあの混乱した設計のバイナリでも20年？を生きた。だからテイクオーバーするものもバイナリ、だけどオンラインネイティヴなものになるはず。ただし、誰もがそれを望む形にできるかは、プラットホームの設計次第。そこに、ジオスペーシャル全体の興廃がかかっている、と @hfu は考えた。
同様に Shapefile が衰退したあとを何が受けるかという観点から、FGDB や mbtiles、GeoPackage の名前が出た。

ここで、FGDB/mbtiles/GeoPackage と vector-tile-spec を対置する概念として、「ネットワークネイティブ」、「オンラインネイティブ」という言葉が使われる。

用語の整理

用語の整理については、2014-05-21 の http://hfu.hatenablog.com/entry/2014/05/21/224650 を参考としていただければありがたい。ここでは、「オンラインデータ」という用語を次のように決めている。

使用可能な形でオンラインアクセス可能になっているデータを指す。伝統的に、インターネット提供されるデータは、直接使用することは不可能なアーカイブ形式で配布されることが多かった。この場合、まずデータを特定し、ダウンロードし、展開し、デスクトップGISソフトウェアで開いて、必要に応じてスタイルを設定し、設定を保存し、初めて使用可能となる。

オンラインデータの場合には、オンラインでアクセスできるリソースそのものがウェブブラウザなどで解釈可能となっているため、上記のようなステップを多数省略することができる。その裏返しとして、処理をしながらデータを取り込む必要があるため、処理の特性に応じて十分にパフォーマンスを発揮できるようなデータの分割方法等の工夫が必要である。最も知られており最も実績がある工夫の一つが「タイル」である。

少なくとも、@hfu がFGDB/mbtiles/GeoPackage と vector-tile-spec を対置する場合には「オンラインデータ」であるかどうかを見ている。

「タイルが基幹、データベースファイルは副次」という概念

これから派生して、「タイルが基幹、データベースファイルは副次」という概念を提示している。タイルもオフラインで使う場合がある。そのような場合、データベースに収めるのがよい。それが mbtiles であり、おそらく Geopackage である。しかし、あくまでタイルが基幹であるべきと考える。タイルはキャッシュ可能つまりオフライン化可能であり、キャッシュの方法は実装に任せたほうが世の中が進みやすいと考えるためである。

Geopackage の技術マーケティング評価

小さなデータなら GeoJSON に、大きなデータなら vector-tile-spec にシェアを喰われてしまう。内部データ形式なら、標準化する必要性が薄い。なので、マーケティングが上手くできないのではないか、と思われる。better Shapefile としては優秀であるが、そもそも Shapefile が押さえていたユースケースを改めて押さえに行くか、というマーケティング問題がある。逆に、そこにニーズがあることを与条件とすれば、悪くは言えない。そういう風に @hfu からは見えている。

感想は、ここに書いてよろしいのでしょうか（汗

オンラインデータにおける用語の定義と、現在の「オンライン公開データ」の問題点については、完全に、賛同します。というか、おおよそ三年近く遅れて、理解できました（汗

実際、CS立体図を開発された戸田さんとお話した際にも、「まずデータを特定し、ダウンロードし、展開し、デスクトップGISソフトウェアで開いて」、更に座標系、フォーマットを変換をして、必要な場所を抽出して、やっと使えるようになる。何よりもそこがネックであると話しておられました。

大きな方向性として、上記の様な作業をオペレートできるような人が増えるに越したことはないのですが、そういう人を増やす努力をするよりも、公開するデータをオンラインネイティブにした方が効率的であろうというのが、現時点の考えです。

整理できていない疑問や意見を投げるかと思いますがご容赦を。まとまった場合はブログかなんかに書きます。

GeoPackage 等のデータベースファイルの役割

Shapefile の代替として GeoPackage を挙げたが、これは従来のオフライン利用のみの世界で代替として優秀であるという意見だ。 Esri の FileGeoDatabas (FGDB) 含めファイルベースのデータベースはデータを扱うというより作業者のプロジェクト全体のデータセットを扱う。この視点からいえばマルチバンドのラスターデータを格納できる FGDB をその代替として提案したいが、仕様が Open 出ない以上は推せない。使いこなせばデータセットは解析を円滑に進められるスキーマを持ち、そのスキーマは再利用できる。一方でこれらを「データ交換フォーマット」としてみたときに Shapefile の代替となり標準となりうる力を持つかを考えると、No であると考える。Shapefile より優れていることは明白だが、Shapefile を捨てさせるほどの利点はない。

データベースファイルは副次という考え方

上記のように思考していると、クラウド・オンラインデータの副次的な受け皿として存在するというのは大変賛同する。 mbtiles、GeoPackage、FGDB でも選択可能だ。

オンラインデータとプラットフォーム

オンラインデータが vector-tile-spec かという点については私はまだイメージできていないし、かといって否定するような意見もまだない。vector-tile-spec の理念や設計を理解した後、私見を共有したい。

私のオンラインデータに対する疑問および、それを取り扱うプラットフォームの機能として興味があるテーマは以下です。この中には私の理解不足による疑問もあると思います。

地物の抽出大規模なオンラインデータが vector-tile として整備されている場合、範囲ではなく特定の地物をどのように検索し出力するのだろうか。例えば国道1号線のジオメトリが欲しい場合などである。
編集差分と衝突の管理オンラインとオフラインのデータのやり取りは必ず共同編集時やデータマージ時の差分管理および衝突管理の機能がプラットフォームに必要となるだろう。Git 的な仕組みがいいのか。

もっとあるのですが、うまく言葉にならないので、もう少し整理します。

@wata909 ありがとうございます。そうなんです、タイルを地理空間情報処理の一級市民にすることができて、デスクトップ GIS もタイルをそのように扱えるようになれば、「まずデータを特定し、ダウンロードし、展開し、デスクトップGISソフトウェアで開いて、更に座標系、フォーマットを変換をして、必要な場所を抽出して、もうそれだけで仕事をした気になる」という世界を脱することができると思っています。

そのためにも、（1）画像タイルの機械学習での活用、（2）標高タイルのマルチパーパスユース及び当たり前に使われる基本データ化、（3）ベクトルタイルの3つの前線が重要だと思っています。新奇なことをすることで、基礎的な利用も（よりよい形で）できるということを示したいです。

結果的に、デスクトップ GIS に対しては、「デスクトップ GIS がやらないなら、ブラウザがやるだけだ」というメッセージングになるような動きを優先しますが、長期的・本来的にはデスクトップ GIS は合流すべき同志だとおもっています。デスクトップ GIS も、オンラインデータで裨益するはずで、まあそのためには proxy 対応とか HTTP/2 対応とか、いろいろ大変なこともありますけれども（笑）。

@PEmugi ありがとうございます。Geopackage に関する技術的評価は、これで、私と @PEmugi との間で共通の理解に至ったような気がします。

vector-tile-spec に関する関心事項について、私は次のように考えます。

（1）「地物の抽出」というのは、データベースの発想では適切な例であるが、実際の社会的な利用においては、あまりユースケースがないと考えている。つまり、先に空間で絞られるのであり、次に属性でフィルタされるという用途に対して最適化すべきである。「国道1号線のジオメトリが欲しい」というユースケースは、プロの現場を除いては、ほとんど存在しない。多くの方が、実際に「国道1号線のジオメトリ」を取り出しても圧倒されるだけになってしまう。例えば、ウェブ地図で大縮尺の「国道1号線のジオメトリ」を取り出しても、ブラウザが落ちるだけであり、逆に小縮尺ならば、すでに表示のためにメモリまで来ているデータをフィルタするだけでよく、データベース発想での検索というものは、ウェブ地図では考えにくいと思っている。他方、プロならば莫大な「国道1号線のジオメトリ」データを抽出したい場合もあると思われるが。その場合はタイルを全部舐めながら引き出せば良い。このプロユースにはリアルタイム性を求められることはないから、ゆっくりやって頂ければ良い。

（2）「共同編集時やデータマージ時の差分管理および衝突管理の機能」についても、プロユースの世界でしか必要がないと考えている。それぞれのプロの現場では、泥臭いものも含めて確立されているので、vector-tile-spec のデータが市場に出回るにあたって新規に検討する「必要」はない。他方、空間的にタイルで切られているので、タイル境界での処理さえ適切かつ自動的に行うことができれば、これらプロユースの管理機能についても、相当速度改善ができる可能性はあると思う。管理機能については、汎用的に考えると必ず速度が出ず、それぞれのプロの現場の管理ロジックに即した泥臭い手法のほうが速度を確保しやすいという経験則を持っており、git 的な仕組みについては、かなり悲観的である。（コードと比べて地理空間情報は、そもそも量が大きく、変更の波及が大きく、表示性能に関する要求が高いので、git のように「悠長に」バージョン管理ができるか、かなり悲観的。）

「Git 的な仕組み」については、「OSMさんがあの大規模分散共同編集環境でそれをプロダクション採用したら、それは使えるかもしれないので検討する。それまでは泥臭く現場レベルでいく。」という感想を持っています。ワードやエクセルが扱うような情報がきちんとバージョン管理されるように人類が進歩すれば、その後ろから地理空間情報は付いていくのかな、という経験的勘を持っています。使えることが証明されれば飛びつくが、使えることが証明されることは近未来にはないのではないか、であるから当面泥臭く行く、という判断です。

@PEmugi タイルの履歴管理については gsi-cyberjapan で kakotile という仕様を考えていた経緯がありますね。 https://github.com/gsi-cyberjapan/kakotile-spec

Apple の TimeMachine のように、時間を指定すればその時点のタイルに戻れるようにするという仕組み。過去のタイルへのアクセス頻度は低いし、そもそもタイル単位では編集頻度は低いのだから、変に差分管理せずにまるごと「名前をつけて保存」しておこうよ、という態度が見られます。kakotile の発想と単純な HTTP の GET / PUT、それに編集チーム内部の連携あるいは編集チーム内が連携できないのであればロックメカニズム、そういったものがあれば、タイルベースの編集プラットフォームは構築可能であろうかと思いますが、今の時点で必要でもないだろう、とも思います。

地理空間情報については、ユースケースの95%は read、5%弱が write であると想定しているし、その 5% はプロの領域だから、そこではまだまだ伝統的なストレージ技術が生き残る、という感触です。

hfu / techno-pop