はじめに
私は国連オープン GIS イニシアティブのスパイラル4「国連ベクトルタイルツールキット」のリードを行なっており、12月2日には、FOSS4G Asia 2018 関連のワークショップとして、スリランカのモラトゥワ大学で OSGeo.JP Workshop for the UN Vector Tile Toolkit を実施しました。ワークショップの資料は公開されています。
多くの国から、基本地図のベクトルタイル提供に関心のある方々の参加を得て、非常に楽しいワークショップにすることができたと思っています。このワークショップの様子は、翌12月3日のFOSS4G Asia 2018 基調講演の資料、また、12月7日に日本で開催された地理文化講演会の資料でもご紹介しているところです。これらの実現に尽力いただいた皆様の、心から感謝しております。
ワークショップの題材としての OSM
このワークショップでは、ハンズオン形式でベクトルタイルを生産・消費する方法をお伝えしたのですが、生産するベクトルタイルの材料としては、下図のとおり、Natural Earth、Global Map Sri Lanka と並んで、OpenStreetMap のデータを活用しています。
国連ベクトルタイルツールキットは、支配的なウェブ地図プラットフォームの基本地図と同じような性能を持つ基本地図を提供したい機関を支援するため、様々な入力データから、相互運用性と性能を確保した形でベクトルタイルを生産・消費することを目標としていますが、今回のハンズオンでは、入手が容易なこれらのデータを活用させていただきました。
目標設定
国連ベクトルタイルツールキットは、様々な入力データの形式に対して柔軟に対応することを設計目標にしていますが、今回のワークショップでは、なるべく 素の OpenStreetMap データから、素直に写像したベクトルタイル を作ることを目指しました。
というのも、今回のハンズオンでは、作業に必要なソフトウェアを最小限に限定するために、リレーショナルデータベースを使わないことを要件としたからです。OpenMapTiles などに代表されるような、imposm3 のようなリレーショナルデータベースへのマッピングソリューションを使うことを断念し、osm.pbf 形式から osmium を使って GeoJSON Text Sequences に変換したデータを、いかに素直な形でベクトルタイルに変換するかが目標となりました。
two-eleven スキーマとその実装
事前分析
スリランカをカバーする領域についての OSM データを私の経験に基づいて分析したところ、OSM データは、以下のいずれかのタグを持っているものが 99% 以上をしめることが分かりました。
非 POI 系列タグ 11 種
- landuse
- natural
- boundary
- waterway
- highway
- buiding
- railway
- route
- aeroway
- place
- leisure
POI 系タグ 11 種
- amenity
- historic
- military
- man_made
- power
- sport
- office
- craft
- public_transport
- tourism
- shop
これを踏まえて、これらのタグを順序よく引っ掛けていって、それに対応したベクトルタイルレイヤ名を割り付け、また最大ズームレベル、最小ズームレベルを割り付けていけば良いと考えるに至りました。
11個のタグ群2セットで OpenStreetMap データを分類するスキーマであることから、このスキーマを two-eleven スキーマと名付けています。
two-eleven スキーマの特徴
two-eleven スキーマは、OSM の元のデータモデルと同様、ジオメトリの型で区別を行いません。ベクトルタイルスタイルでは、ジオメトリの型を判断して描き分けることができるわけですから、シンプルさを確保するという観点で、この区別のなさは合理的だと思っています。
また、route と public_transport という、公共交通系のデータが他のデータからうまく分離するのも、データ構造を適切に露出するという点で、少し期待できます。
描画との関係
描画の際にも、概ねこの順番で下から並べていけば地図になると思っていますが、POI 系タグの最大勢力である amenity についてだけは、描画順番を一番最後（一番上）に移した方がよいと思っています。
ハンズオン時点でのスタイルの実装も、必要に応じて参照いただければと思います。
実装
実装は、国連ベクトルタイルツールキットの spinel-produce の modify.js の 66 行目から216行目にあります。
two-eleven スキーマの位置付けについて
現時点で、私は two-evelen スキーマを学習用のスキーマであると位置付けています。実用になるかどうかはまだ分かりません。しかし、マスターデータに忠実な構造のベクトルタイルスキーマ というアプローチは、重要かもしれないと思っています。
なぜならば、ベクトルタイルは、地理空間情報のデータ構造をウェブに露出する手段であるからです。
また、やや遠い将来において、書き戻す(write back)ことができるベクトルタイルというのは効率化の観点から重要になってくると思います。その観点から、ベクトルタイルのスキーマというものは、表示用のスキーマということに矮小化されるべきではなく、地理空間情報のネイティブのデータ構造をそのまま反映するべきかもしれない、と感じているところです。
ベクトルタイルスキーマについては、まだまだ実験と失敗と改善の余地があると思います。Fork me、と私はここで申し上げたいと思います。
引用
私は今までナポレオンの軍を倒せと言ってきたが、今はこう言うべきだろう。フランスの自由を救おう - ジュゼッペ・ガリバルディ
実際には、ジオ＋ウェブの界隈には、ナポレオンの軍などいませんけれども、国連事務総長の新技術戦略にもあるとおり、パートナーシップをうまく作り出して、技術が全体的に進むようにできればいいですね。
See Also
ちなみに、Natural Earth の海岸線ベクトルタイルを作成する方法は、hfu/natural-coast で共有しています。