planet.osm.gz 形式のデータおよび Natural Earth のデータからバイナリベクトルタイルを生産するツールである OpenMapTiles を使うにあたっての細かなノウハウを紹介します。
gh:openmaptiles/openmaptiles との付き合い方
このソフトウェアの一番大きな特徴は、バイナリベクトルタイルを作成するための既存・新規の様々なツールを Docker (docker-compose) を使って構成管理しているところですね。このおかげで、かなり複雑な生産体系を数コマンドで新規環境に移すことができます。これが、最も大きな強みかと思います。
他方で、Docker の技術は動いてきていることと、gh:openmaptiles/openmaptiles の構成がやや特殊なことから、お使いになる環境に合わせる作業が必要になることが多いです。
このソフトを使うにあたっての考え方は、次のようになると私は思います。
- 環境と合わせ込むために、いくら泥臭い設定をしてでも、まずは何とか動かすことができるようにすることを追求する。
- 使い方が安定してきたら、それに安住せず、gh:openmaptiles/openmaptiles の進展に追従できるように、github レポジトリそのままの内容から最小の変更で動かすことができるようにする。
泥臭い設定をすることによって、Docker の仕組みを学ぶことができますし、その作業は無駄にはならないと信じて quickstart.sh や Makefile、.env をいじっていくことが必要です。どうしてもうまく動かない場合には、もしかすると違う OS 環境で試してみるのも良いかもしれません。別の OS 環境で得た知見が、もとのターゲット OS での設定に役立つかもしれません。
gh:openmaptiles/openmaptiles の技術的特殊さ
gh:openmaptiles/openmaptiles を使うにあたって技術的な難しさが発生する要因を知っておくことは、それぞれの環境で解決をお考えになるにあたって役に立つかもしれません。私は、次の２点が要因であると思います。
- データを扱うためのボリューム（ストレージ）について、Docker が古くから使っているが、必ずしも環境によっては安定していないバインドマウントによって確保している。
- ホスト側で make や gawk, bc などの基礎的なツールを実行するように組んである。
これらの要因が、それぞれのホスト環境で問題を起こします。
Windows 7 の場合
Windows 7 の場合、Docker も virtualization 環境前提の新しい実装ではなく、VirtualBox を用いる Docker Toolbox on Windows を使うことになります。この場合、難しさの本質は次の２点になります。
-
ボリュームのバインドマウントのためのパスの指定が、VirtualBox 上のホスト（docker-machine）からの指定になる。加えて、Windows 7 上で docker を扱うために用意されている MINGW が、パス指定を調整してしまうことがある。これをキャンセルするために、パスの最初の / を // と書くことが有効である場合がある。
-
make は MINGW に用意されていない。
私の場合には、quickstart.sh から本質的に重要なところを抜き出し、make を呼んでいるところをコマンド直書きに展開したシェルスクリプトファイル openmaptiles.sh を作成し、バインドマウントされているフォルダを ボリューム によって差し替えることによって、動かすことができるようにしました。
ただし、この方法だと必ずしも最新の gh:openmaptiles/openmaptiles に追従するのに便利ではないので、gh:openmaptiles/openmaptiles を呼び出すための兄弟 docker container を用意する方法に移ることができないかと悩んでいます。
macOS の場合
macOS はより UNIX ベースなので、比較的困難は少ないと思っています。私は現在、ポータビリティを確保するために、homebrew なしで動かす方法を確立しようと思っていて、ここでもボリュームの扱いで悩んだりしています。
いずれも、より洗練された方法を確立できれば、あらためて共有したいと考えています。