藤村 英範/ベクトルタイルとボクセルタイルによるシンプルで自由な可視化について

Data Visualization Japan Meetup 2021(2021年12月29・30日開催)における、藤村 英範さん(国土地理院)の講演です。国連ベクトルタイルツールキット(UNVT)の取り組みと、点群のボクセルタイル化について紹介します。


国土地理院に勤務しています、藤村と言います。今回、ベクトルタイルとボクセルタイルについてお話しさせていただきます。

オープンソースのプロジェクトとして「国連ベクトルタイルツールキット(UNVT)」 という形でやっておりますので、その流れの中でのご紹介になります。

自己紹介

情報工学の採用で国土地理院におりまして、基本的に私も地図を専門にしている人間です。ベクトルタイル——データをいかにお客さんのところにお届けするかについて専門的にやらせていただいています。

国連に出向した時に、私たちが持っていた技術をオープンにすることができて、パートナーシップという形でお話を進めております。

国土地理院 地理空間情報部

私たちがやっていることは、地図のデータを伝えていくこと。国土地理院が作っている昔ながらの地形図を伝えていくこと。そしてデータを通じて人と人をつなぐデータとデータを重ね合わせてつなぐといったことです。

地理空間情報部は1960年代には「印刷部」だったんですね。紙の地形図を作って出していくということをやっていて、その DNA があるということで、しっかりデータを表現して出していくことをやっております。

もともと印刷物の地図をやっていたので、**その素直な展開として Web 地図をやる。**私たちが持っている地形図を、Web で必要とする人がいるならしっかりお届けしたいという考え方で仕事をしています。

重視していること

日本の地理院地図をやっていますし、他の国や国際機関の地図についても Web 地図技術をお手伝いしている中で、**私たちがすごく大事にしているのは「全国一律・シームレスに出していく」**ことです。

非常に良い技術はたくさんあるのですが、それが全国どこでも展開できる、また我々のリソースで展開できることを非常に大事にしていて、結果としてスケーラビリティや持続性を重要視しています。

**「やはりタイルだ」**というのを日頃から思っておりまして、その方向性でご賛同いただける方が増えていくといいなと考えております。

地理院のデータだけでなく、いろいろなオープンな地理データに我々の Web 地図技術を適用して、多様な可視化ができないかと考えています。私たちはソフトウェアにそれほど詳しいわけではないコンテンツの人間なので、非常にシンプルな技術を自由に使うということでいろんなことを試しています。

① 国連ベクトルタイルツールキット(UNVT)

地図に自由を与えていくというテーマです。

開発の経緯

  1. 国土地理院にとって最も大事なのはコンテンツ(地図) だが、それを出していく技術も持っている
  2. しかしコンテンツを Web 地図にする技術がタコツボ的・ガラパゴス的になってしまうと、我々のコンテンツがなかなか出ていかない。だからこの技術を自由で開かれたものにしていく
  3. 国土地理院の技術は割と高く評価いただいていて、国連事務局から「能力構築をしてくれ、職員に技術を伝えてくれ」という機会があった
  4. 組織を超えて技術を共有するやり方の中で、特にソフトウェア技術はオープンソースが非常に魅力的だということで、オープンソースソフトウェアという形で技術移転をしている

「空っぽ」であることの意味

やり方としては、**我々自身がソフトを作るわけではありません。**既存のオープンソースソフトウェアで非常にいいものをうまく組み合わせて、内製でスケーラブルな Web 地図を作る。そのノウハウをツールキットという形で整理しています。

ソフトウェアをスクリプトで組み合わせているだけなので、ソフトウェアプロジェクトとしては実は空っぽなんですね。ただ、空っぽであるからこそいろいろなものを詰め込むことができます。

データをタイルにして出していく際、軽くしないとサーバーのリソース上問題がある。そういった最適化のノウハウを載せていく。人から人にノウハウを伝えるのに適しているのかなと思っています。

そしてフリー&オープンなので分散がしやすい。災害対応の際に現場のなるべく近いところで別のサーバーを立てるといった可能性を持っています。

5つの工程

元データ → タイル生産 → ホスト → スタイル → 最適化(そして少しビジュアライズ)。

基本的にあるものをうまく使う。どう使うかというノウハウで勝負しようと考えております。

作業面では——

  • GitHub ——ノウハウをコードの形でシェアするのに非常に便利
  • Raspberry Pi ——能力構築の際、クラウドの難しいところを捨象して説明したいので超小型PCをよく使う
  • コマンドラインインターフェース ——我々の分野(地理空間情報)は GUI が多いのですが、バッチでやっていく

ウェブサイトは unvt が略称で、GitHub Pages に簡単なページを置いています。リポジトリは現在36あり、いろんなスクリプトを共有しています。

国連オープンGISイニシアティブ

UNVT は国土地理院の職員が作ったプロジェクトですが、上の方では「オープンソースソフトウェアは GIS 以上に大事だ」と考えられていて国連オープンGISイニシアティブの中の10いくつかのプロジェクトの一つになっています。

このイニシアティブは参加型で、産学官のたくさんのプレイヤーが参加しています。UNESCO や ESCAP、アフリカの機関など国連組織が多いですが、国土地理院、OSGeo 日本支部、OpenStreetMap 関連、企業、大学も多く入っておられます。ご興味があればぜひご連絡ください。

基本的な考え方

国土地理院は自分たちで Web 地図を運営する必要があると思っています。**紙で地形図を作っていたので、Web でも地形図を出していく。**そのためのノウハウが UNVT というソフトウェアで実現されています。

この部分はオープンに共有していける——**「皆さんのデータを、同じソフトウェア UNVT を使って、あなたの Web 地図を作りませんか」**ということをやっています。

最初のものが私自身で、国連事務局(国連グローバルサービスセンター)で、国土地理院と同じ技術で地図を作るということをやりました。UNVT が共有されているので、同じバックグラウンドで発表していける。

「オープンソース」というより「コードシェアリング」

最近考えているのですが、我々がやっているのはなかなか本格的なオープンソースソフトウェアではないんだろうなと。言葉を考えてみると「コードシェアリング」に近いのかなと思っています。非常に軽いスクリプトを共有している。

我々の本業はコンテンツです。Web 地図で出していくためのノウハウをシェアしたい。しかし「オープンソースソフトウェア」と言うと、皆さん非常にヘビーウェイトなもの——8万行くらいのソースコードがあってしっかりプロジェクト管理されているもの——を想像される。UNVT はそれほどでもない。

整理してみると、我々のスクリプトはだいたい80行くらい。8KB ほどの単純なスクリプトをかなりカジュアルにシェアして、「これであなたのデータを変換できるか」を議論しているのがメインです。

地図の世界の特殊性

普通のオープンソースソフトウェアなら、プログラムのコードが8万行、データが800MB。

でも地図の世界、特にベースマップの世界は違う。スクリプト自身は80行くらいなのに、800GB ほどのデータを扱う。

データが重いコンテンツをいかに通していくか、しっかりホストしていくかが重要になる。ソフトウェア自身というより、データをいかにしっかり変換するか、いかに安定的・持続的にホストするかが我々特有のノウハウなのかなと思います。

そのノウハウの世界は、ソフトウェアだけを出しても伝わらない。実際にやってみせることが大事です。

② Adopt-a-Geodata ― データに愛着を持つ

UNVT のサイドプロジェクトとして「Adopt-a-Geodata」(里親地理データ、といった感じ)をやっています。

データに愛着を持って、実際に変換して、実際にスタイルをつけて、実際に運営する。このあたりのノウハウをみんなで共有していこうというプロジェクトです。

**オープンデータはたくさんあり、緯度経度がついた地理データもたくさんあるのに、まだベクトルタイルになっていない。**シェープファイルや GeoJSON のままで重く、なかなか見られない。**我々は地図屋なのですぐ地図になってほしいのに、まだ地図になっていないデータが非常に多い。**そういうオープンな地理データをベクトルタイルにしていくプロジェクトです。

ウェブサイトは optgeo という名前で、リポジトリは150ほどあります。とにかく色々作っていく中でノウハウも溜まっていきますし、逆に生まれてきたソフトウェアもあったりします。

最近のものでは——デンマークの住所データがとてもいいと言われるけれど実際に見た方は少ないだろうので実際に見てみよう、とか。イギリスの Ordnance Survey のベクトルタイルを Raspberry Pi に入れて、どの現場に行ってもイギリス全国の地図が見られるようにしてみよう、とか。

例1:南極・昭和基地の地形図

日本国内以外でも地形図を作っている例があります。南極の昭和基地です。2500分の1くらい、都市計画図と同じようなものを実は昭和基地について作っています。

南極のプロジェクトでも「昭和基地をスマートシティにしたい」とおっしゃっているところがあるので、日本で使っている最新の技術を当ててみたらどうなるかということで、昔ながらのシェープファイルだった南極の地形図データをベクトルタイルにしてみました。

すべて GitHub で公開していて、UNVT の仲間たちでみんなで改善しています。カジュアルにどんどんコミットしていくので、本格的なソフトウェアプロジェクトより回転が早く、身が軽い。

南極についてはコミュニティをしっかり作ろうと頑張っています。**南極に行かれる隊員の方は出発時はニュースになるのですが、船に乗って基地で実際に仕事をされている間、日本の我々となかなか会話が難しい。**そこで GitHub の Discussions を使って議論を進めようとしているところです。

きっかけをくださったのが、今まさに越冬隊で出発されている隊長です。大学の先生で南極にも何度も行かれている方が、Raspberry Pi に非常に詳しくて——「南極ではまだ紙の地図に鉛筆で書く世界が多いけれど、Web 地図をやってみたい」とおっしゃった。

**スマートフォンやタブレットを使うノウハウはあるけれど、インターネットがどうしても遅いので、サーバーを南極の基地や雪上車の中に置きたい。**そこで我々の技術が役に立つのではないかと。ベクトルタイルと、安価な車載用 GPS を Raspberry Pi で使うという2つのプロジェクトを進めています。

例2:アルバニアと OpenStreetMap

JICA のプロジェクトでアルバニアの国土地理院に技術移転をしているのですが、最初に問題になるのがデータがないこと。

**データがないけれど、Web 地図の技術——特にベクトルタイルの技術——はお伝えしたい。**そこで非常に役に立ったのが OpenStreetMap のアルバニアのデータです。実際にベクトルタイルに変換する手順をすべて GitHub のリポジトリに置いて共有しています。

国連の職務でも OpenStreetMap を非常にたくさん使わせていただいていて、ノウハウもあるので非常に扱いやすい良いデータだと思っています。

例3:基盤地図情報

今度は逆に、国土地理院がもともと出している基盤地図情報です。

組織として正式にベクトルタイルを出すまでには少し時間があると思うので、UNVT のコミュニティで(もちろん仕様承認を取って)変換してみるということをやっています。

さらに Mapbox のストーリーテリングの技術を使って、基盤地図情報ベースで東京の観光案内のようなものを作ってみました。基盤地図情報のようなデータであっても、こういう Web 地図の技術にしっかり乗るということを実証しています。

③ 地球観測データ × ベクトルタイル

Earth Observation & Vector Tiles(EOVT) という枠を別途考えています。

地球観測は「とっても本格的なデータ」だと思われていて、専門のソフトウェアがないと見られない。「すごいデータだ」とみんな知っているけれど、実際にどういうものかを見る機会が少ない。そこで親しんでもらうために何かできないか、と。

もう一つ——地球観測のデータは「宇宙には国境がない」世界で、国境も行政界も地名もない。そこに我々が持っている地形図のデータをうまく載せると非常に価値が出てくるのではないか。

従来は画像タイル同士を重ねると滲んでしまい、情報が重ならなかった。しかし本質的に画像である地球観測データに、道路や建物といったベクトルデータが乗ると、これまで以上に価値が出せるのではないか。

ラスターをベクトルタイルにする

お餅からお米を作るような話かもしれませんが、ラスターデータをベクトルタイルにするというのが面白い。画像のピクセル1個1個をベクトルにしていく——このアプローチですごく価値が出たという話です。

JAXA さんが出している高解像度の土地利用土地被覆データがあります。地球観測データそのものというより、JAXA さんが処理をして「ここは水域」「ここは都市」「ここは水田」と分類したリモートセンシングのデータです。

最近は解像度が非常に上がっていて、建物一軒一軒とピクセル1個1個があまり変わらないくらい。

地図屋の人間は縮尺をすごく大事にするのですが、縮尺をうまく使って情報を抽象化したり詳細化したりというところが、もう少し加えられるのかなと思って頑張りました。

この作例には3つのデータが使われています。

  1. JAXA の高解像度土地利用土地被覆データ ——1画素1画素に属性がついていて、それを1個1個四角形にしている(青は水田など)
  2. 地理院地図のベクトルタイル(地理院ベクタ)——地名・道路
  3. 標高タイル ——街の中に急に傾斜地があり、奥に山がある、という地形が分かるように

この3つを素直に組み合わせるだけで、こういった見せ方ができる。

やってみて面白かったこと

① 全国シームレス

JAXA も全領域について土地利用土地被覆データを作られていますし、標高も地図も全国出しているので、一度技術的に作ると全国どこでもできる。

② 早くて、ぼやけない

昔ながらの画像ベースのタイルはパタパタと遅かったりしますが、よく設計されたベクトルタイルは画像タイルより早い。

そして**いくら拡大してもぼやけない。**昔ながらの Web 地図では、リモートセンシングのピクセルと Web 地図のピクセルが必ずしも一致していないので拡大するとぼやける。これは1ピクセル1ピクセルをすべて四角形にしているので、いくら拡大しても四角の筋がシャープに残る。

なお、「精度は担保できないところが見えているのでは」と心配しがちですが、UNVT や Adopt-a-Geodata は職務上の精度の責任から少し離れた実験的な取り組みなので、まず技術的にどこまでくっきりできるかを試している。そこがとてもいいところかなと思っています。

③ 地形にぴったり張り付く

これは Mapbox GL JS v2 という優れたソフトウェアのおかげです。建物がぺったり張り付くのは少し気持ち悪いのですが、3次元に立てるとまた違った見せ方になるでしょう。地図記号もうまく立っていて綺麗です。

④ ピクセルから音声合成

ピクセルをクリックすると、そのピクセルの属性——水田なのか落葉樹林なのか——を音声で読み上げるようにしています。

凡例はとても大事ですが、貴重な画面のピクセルを占めてしまう。音声をうまく使って、知りたいところをクリックするとそこの凡例情報が出てくるというのができるようになった。これもベクトルタイルの良さだなと思います。

作り方

まさに80行程度のスクリプトです。単純なデータをどんどん流していく中で——

  • GNU parallel ——コマンドラインで並列処理
  • GDAL ——地理空間データ処理のライブラリ
  • tippecanoe ——ベクトルタイル生成

これらを組み合わせるだけでタイルのデータを作っていく。このコードはこれまで自分でもいろいろやっていたけれど公開できなかった。今 UNVT という流れがある中で公開していけるのが非常に面白い。

ノウハウとしては、たとえば「とにかく一時ファイルを作らない。1つのパイプラインで処理するととても早い」といったものがあります。

標高タイルの補足

国土地理院は 256×256 ピクセルの PNG 標高タイルを組織の事業として出していますが、Mapbox の新しいライブラリは WebP の512ピクセルタイルを使っておられます。

我々のデータもオープンデータなので、コミュニティとしてこのデータを変換して Mapbox GL JS v2 から参照できるようにしました。技術もタイルもオープンにしているので自由に使えます。いいデータを使うと地形がよく切れて見えるようになり、これから高精度の標高をたくさん作ってまいりますので、Web で当たり前に使えるようになるといいなと思っています。

④ UNVT Portable ― 現場を目指して

クラウド上にあるサーバーソフトウェアを、なるべく現場に近いところに配備できるようにする話です。

使うのは Raspberry Pi約100ドルのコンピュータで、一通りの Linux 環境が作れます。スマートフォンで使っている CPU ですが、割と我慢強く使えば結構いろんなことができます。

2020年に東京で国連の地理空間情報・防災関係の会議をやる予定でした(コロナの出だしで実施できず)。いろんな国の方に能力構築をする中で、クラウドへのアクセスが事情で難しかった。そこで Raspberry Pi を配って、その場のテーブルでやってみたらどうかというのが始まりです。

2021年はテレワーク・在宅勤務が多い中で、**その機会をうまく使って Raspberry Pi でどこまでいけるかをかなり進めることができました。**南極の話にも関わってきますが、**ラックに入ったサーバーでやっていた仕事がどこまでいけるか。**5台ほど並べて使っています。

情報工学の人間なのでやっていて非常に楽しかった。すべてがこの小さなコンピュータの中で閉じる。でもインターネットで繋がっていて、インターネットに対するサービスを全部出せる。昔ながらのインターネットの楽しさが再現できたのかなと思っています。

容量の制約がなくなった

それ以前は GitHub Pages の無償ホスティングを使っていたので、元データ500MB程度、ベクトルタイルにして1GB以内という制約が自然にありました。

UNVT Portable を使うとその制約がなくなる。Raspberry Pi にハードディスクを繋ぐだけで500GBが簡単に作れるので、ホストできるタイルの容量の制約がなくなった。これは非常に大きかった。

基本図・地形図をやる時は何百ギガというデータを扱う。それに近い規模のものが Raspberry Pi でできるようになったので、その領域をやってみようと考えました。

⑤ ボクセルタイル ― 静岡県の点群を変換する

そこで最初に狙ったのが、このイベントの最初でもお話しされた杉本さんのところ——静岡県のポイントクラウドデータです。大きいことで有名なので、ボクセルタイルにしてみようと。

ボクセルとは

画像の単位がピクセル。3次元を格子状に切った中の1個の単位がボクセル(ボリュームエレメント)です。四角い格子で切って、1個1個がサイコロのようなもの。

背景 ― 3次元空間ID

デジタル庁の重点計画で、モビリティ関係で「3次元空間ID」 という話が出てきました。3次元で実空間の位置情報を一意に特定するというものです。

経済産業省の資料でも具体化が進んでおり、検討体制にデジタル庁・経済産業省・国土交通省・国土地理院が入っていて、我々も混ぜていただいています。

仕様書を探してみると、**「3次元空間を立方体のボクセルにする」**とある。なるほど、立方体のボクセルにするのかと分かってきました。

国土地理院は実際のデータを扱う非常に現業的な部署なので、実際にやってみせる——ボクセルを作ってみるのは我々の役割かなと思い、今年在宅勤務の時間なども使って、Raspberry Pi を6〜7台ぐるぐる回して作業をしています。

KID(空間ID)の C ——ABC と来て3つ目のプロトタイプです。3回作ってやっと少し落ち着いてきたという感じです。

技術

本当にシンプル、80行以下の世界です。

  • Ruby でメタデータ・パラメータを作る
  • PDAL(Point Data Abstraction Library)で点群を変換
  • tippecanoe でベクトルタイルにする

静岡県の LAS データ(点群)を、また「餅を米にする」的な感じでボクセルにして、さらにベクトルタイルにしていく——これを実質1個のパイプラインで変換しています。1つのパイプラインでやるのは UNVT ファミリーでよく使う技術です。

結果

静岡県の点群のうち半島側のデータを変換しました。高架の道路があるところ、山のあるところをボクセルで見せるとこういう形になります。非常に早く、グリグリ動くので、動かしているうちに感覚がつかめてきます。

我々の特徴は「なるべく多くのクライアントで動かす」ことを重視して、割と軽く作ることにこだわっている点かもしれません。1万円を切るような Android スマートフォンでもなんとか動く軽いものを作るというカルチャーがあるので、パッと見た感じあまり魅力的でなくても、動かす中で立体感や実際の状況が分かるものを作りがちです。

それでも白いところに走っているのはおそらく車かなというものが映っていたり、本物のポイントクラウドとよく似て見えます。そしてデータ量は何十分の1軽い中でなるべく伝えるべきものを伝える、という地図的なカルチャーでやっています。

ズームレベルを1つ増やすとボクセルのサイズを半分にするという形にしていて、これは 4m の空間分解能のボクセルです。高架の道路、鉄塔、そして非常に面白いのが高圧線——電線がボクセルになるとすごく太って見えるので、電線に引っかかりたくない人、ドローンを扱う時には非常に可能性があるのかなと思ったりしています。

実際に作って掴みたかったこと ― 「事実の構造」

最終的には標準化をして相互運用性を高めることが大事ですが、その前にデータの構造をよく見る必要があるし、実はそのさらに前に「事実の構造」——実世界が実際どうなっているのかを把握することが大事なのかなと思っています。

地理空間は5次元です。緯度経度(XY)、高さ(H)、時間、そしてズームレベル。

でも実際にはほとんど2次元なんですね。

  • 緯度経度方向は4万kmあるのに、高さはざっくりプラマイ10km。しかも人間は土を離れては生きられない。空中でずっと生きている人はほとんどいないし、地下でずっと生きている人もほとんどいない。基本的に地表という薄い層に対して、緯度経度と比べたら非常に薄い
  • 時間は流れているけれど戻ることはないので、一度作ったものを再利用することがなかなかない。ここも薄い
  • ズームレベルは特殊で、むしろデータの生産量を決めるパラメータ

つまり、3次元にしても時間を入れても、結局は緯度経度の方向が非常に深い——これを実際にデータを作ってみて改めて認識しました。

空間IDをやっていく際も、タイルは基本的に XY で割るのですが、タイルの技術をうまく使えば、3次元であろうが時間変化があろうが、かなりいろんなことができるのではないかと最近思っています。

おまけ ― 環状配色

地図アートという素晴らしい技術があって、1次元の数値に対して循環する色をつけていくというものです。

先ほどのポイントクラウドにこの配色を入れると——**同じデータなのに全く見えるものが違う。**非常によく分かりますし、先ほど申し上げた高圧線も非常に分かりやすく見えます。

(※ サーバーが壊れてしまって現在は全部は見えていません。修復とデータの生産をやり直しているところです。ご関心ある方は直接ご連絡いただければご案内できるかと思います。)

最後に

国土地理院がやることは、クライアントが目標を達成するにあたって、我々の専門性で貢献していくことなのかなと思っています。

我々は政府の中の機関なのでクライアントは政府機関が多いのですが、いろんな方が目標を達成するにあたって、地理空間のノウハウをご提供することで貢献できればと思っております。

時間管理が申し訳なかったのですが、私からのお話は以上とさせていただきます。どうもありがとうございました。

Built with Hugo
Theme Stack designed by Jimmy