本記事はベクトルタイル Advent Calendar 2021の12日の記事です。
今回は僕が長年関わっているOpenMapTilesについて紹介と(あくまで個人的な)展望について書きます。
OpenMaptilesとは何か
OpenMapTilesとはOpenStreetMapなどのデータを使って簡単にベクトルタイル一式を作る仕組みです。
ほとんどの物がDockerをベースに作られており、Docker Composeの環境があれば(amd64なら)簡単にベクトルタイルが作成できます。
具体的には ./quickstart.sh japan などと打つだけで日本のベクトルタイル一式がそろうという物です。
また、OpenStreetMapなどのデータとありますが、具体的にはOpenStreetMapとNatural EarthとWIkidataを使っています。
日本におけるホスティングについて
OpenStreetMap Foundation Japanではさくらインターネットの支援を受けて日本独自のタイルサーバを運用しています。
具体的にはさくらのナレッジにて記事を書いているのでそちらを参照してください。
OpenMapTilesの今後の展望について
以下の内容はOpenMapTilesの中を見てないとなんのこっちゃな内容なのですが、とりあえず書きます。
まず、最新のOpenMapTilesはv3.12.2ですが、リリースからかなり経っていてそろそろv3.13がリリースされるという状態です。
とりあえずv3.13で入る予定の大きな変更点を記載します。
- nameのi18nの扱いの変更
- OpenMapTiles toolsがv6.1に変更
- 上記に伴ってMID_ZOOMという概念が登場
もちろん、OSMのデータの取り扱いについてのたくさんの修正も入っています。
nameについては直接デザインには影響ないですがi18nを意識したスタイルを作ってる人は注意が必要かもしれません。
また、OpenMapTiles tools v6.1からMID_ZOOMという概念が生まれました。
これは単に空のタイル(属性が水のみの場合など)から上のズームをコピーして作るという仕組みで、Planetなどの高速化のために使われています。
さて、今後の展望としては、まず新しいNatural Earthへの対応が挙げられます。
というか、Natural Earthがついに5.0にバージョンアップされました。
これによって現在取り込みができない状態になっているというバグがあるのですが、Natural Earthのバージョンアップによって、古いgdalへの依存性が解消される可能性があります。
(古いgdalへの依存というのはNatural Earth 4.0自体がベクトルデータとして整合性がおかしい箇所があり、新しいgdalではそれを弾いてしまうという問題(データバグ)がありました。)
これはすなわち、OpenMapTiles toolsで古いgdalを参照したPostGISのdocker imageを使わざるをえないという状態から脱却する可能性があります。
何が言いたいかというとPostgreSQL 9.6ベースから新しいPostgreSQLへの対応です。
ただ、PostgreSQL 11からjitが有効な場合にST_ASMVT関数が遅いという問題もありますが、ひとまず検証が可能になるというところは大きなポイントとなります。
次に、大きなポイントとしてはMAX_ZOOM=15への対応が挙げられます。
OpenMapTiles自体はMAX_ZOOM=14までのタイルの生成までしかできていません。
元々はOpenMapTIlesのメインの開発会社であったKlokantechの方から「ZOOM 15はデカすぎて扱えないよ(意訳)」みたいなコメントがあったのですが、メイン開発者のnyurikがPostGIS ConferenceにてZOOM 15に対応を示唆した事もあり、今後はZOOM 15を目標とした開発が行われる可能性が大きくなります。
ちなみにZOOM 15で動かすとなると単純にプロセッシングの時間も増えるのでしばらくはZOOM 14のままで行くなどの対応も必要となると思います。
まとめ
つらつらと書きましたが、とりあえずOpenMapTilesはアクティブなプロジェクトとしてベクトルタイル生産の一つを担っています。
最近では大きな対抗馬としてTileMakerなどが現れています。
OpenMapTilesはSQLが書ければコミッターになれるという点がユニークだと思います。
興味を持ってくれたら是非コミットをしてみてください。
