KotobaMediaではカスタム地図サービスを提供しており、その土台のひとつが、お客様のサービスの上に載るベースマップタイルです。現在のメインのベースマップは、OpenStreetMapをベースにした、日本向けの汎用地図です。さらに、日本で使いやすいように、結果が良くなる部分では公的なオープンデータも取り込み、スタイルや優先度を調整し、行政界の扱いがOpenStreetMapと異なる場合には日本側の立場も反映しています。
この投稿では、その地図をどのような流れで更新・公開しているのかを概観として紹介したいと思います。必要になるたびに手作業で地図を書き出して差し替えているわけではありません。ソースデータを更新し、新しいタイルセットをビルドし、管理された手順で公開するところまでをパイプライン化しています。そうすることで、毎回のリリースを場当たり的な作業にせず、地図を継続的に最新に保っています。
固定されたビルド環境
定期ビルドが動き出す前に、ベースマップのロジックは必要な補助アセットと一緒に、バージョン付きのランナーイメージとしてパッケージ化しています。このイメージは本番環境に昇格させる前にテストされます。また、ビルドが依存する比較的静的な補助データもあらかじめ組み込んであるため、定期ジョブ側では日本のデータ更新とタイル生成に集中できます。実運用では、これによって地図生成ロジックが意図したリビジョンに固定され、利用者に見えないところで勝手に変わってしまうことを防げます。
日本データの差分更新
そこから定期ビルドのサイクルは、日本向けに使っているOpenStreetMap抽出データの更新から始まります。毎回すべてをゼロからダウンロードするのではなく、永続化している抽出データを保持し、そこに最新差分を適用してから、日本のカバレッジ境界で再度クリップしています。これにより、OpenStreetMapの継続的な編集をきちんと追いながら、パイプラインをより高速かつ効率的に回せます。現在は週次で更新しており、1回の更新は最初から最後までおよそ15分です。
日本向けタイルセットの生成
更新済みの抽出データが用意できたら、それをPlanetilerベースのビルドに渡します。このビルドは、優れたProtomaps basemapを土台にしています。中核となるソースは引き続きOpenStreetMapですが、それだけではありません。海岸線、土地被覆、境界線、日本固有の鉄道や交通文脈を補うデータセットも使っており、地図全体の整合性と見やすさを保っています。その一方で、最新のOpenStreetMapの詳細を取り込むことで、ローカルな情報の鮮度も維持しています。このバランスは私にとって重要です。地元で見ても自然で、実際に使いやすい地図にしたいからです。
2段階での公開
ビルドが完了すると、新しいPMTilesアーカイブが生成されます。まず日付入りの不変な配置先にリリースし、それが成功してからライブサービスの参照先を新しい版へ切り替えます。私は、稼働中のファイルをその場で置き換えるより、この方式を好んでいます。利用者がアップロード途中の成果物を見ることはなく、必要なときには過去のリリースをロールバック用に残しておくこともできます。
運用面では、タイルは場当たり的な更新ではなく、定期ワークフローを基本にしつつ、必要に応じてオンデマンドビルドを追加する形で管理しています。データ更新、実行、公開といったパイプライン層を担う部分と、地図そのものの構成を定義するbasemap repositoryは分けています。私にとってこの分離は重要です。生成されるタイルの安定性が、パイプラインの都合そのものに引きずられるべきではないからです。
もし私たちのタイルを使っているなら、それらが定期的なプロセス、固定された処理、そして信頼性を意識した明示的なリリース手順から生まれていることを知ってもらえればと思います。
お読みいただきありがとうございました。KotobaMediaのベースマップの使い方に興味があれば、サンプルページをご覧ください。地図ベースのソリューション構築についてご質問があれば、ぜひお問い合わせください。