OpenStreetMapの新しいベクタータイル

 (tech.marksblogg.com)
3 ポイント 投稿者 GN⁺ 2024-11-20 | 2件のコメント | WhatsAppで共有
  • OpenStreetMapは長年、静的なPNGベースのラスタタイルを提供してきたが、今ではMapbox Vector Tiles（MVT）形式のベクタータイルのホスティングも開始し、地図活用の幅が広がっている
  • ベクタータイルではスタイルやレンダリングルールを利用者が調整でき、タイル内の情報抽出やラベル言語の切り替えのような機能を実装する余地がある
  • メインのOSMウェブサイトはまだラスタタイルを使っているが、新しいベクタータイルは別のウェブデモ、QGIS、Leafmapで直接確認できる
  • Burj Khalifa付近のz14タイルの例では、114KBのMVTが1.4MBのJSONに変換され、POIレイヤーには474件のレコードと複数のトップレベルレイヤーキーが含まれている
  • tiles2columnsを使うと、指定したバウンディングボックスのOSMベクタータイルをダウンロードしてGeoPackageまたはParquetに変換でき、更新されたOSMデータをファイルベースの分析にすぐ活用しやすい

OSMタイルが変わるポイント

  • OpenStreetMapはこれまで、レンダリングルールとスタイルがあらかじめ決められた静的PNGラスタタイルで地図を提供してきた
  • 新しいホスティングでは、Mapbox Vector Tiles、つまりMVT形式のベクタータイルを提供する
  • ベクタータイルを使うと、最終利用者が地図表現をより直接的に制御できる
    • スタイルとレンダリングルールの調整
    • 各タイルに含まれる基礎情報の抽出
    • より鮮明な地図画像の表示
    • ラベル言語の切り替え可能性の確保
  • OSMのメインウェブサイトは依然としてラスタタイルを提供している
  • 新しいベクタータイルはウェブデモで、ほとんどのスマートフォンやデスクトップ端末から確認できる

実習に使ったツール

  • 例ではPythonと複数の地理空間ツールでOSMデータを可視化・分析している
  • 基本のインストールツールにはjq、python3-pip、python3-virtualenvが含まれる
  • Python仮想環境には次のパッケージをインストールしている
    • leafmap[maplibre]
    • mapbox_vector_tile
    • morecantile
    • notebook
  • DuckDBでは次の拡張を併用している
  • 地図レンダリングにはQGIS 3.40を使用している
    • QGISはWindows、macOS、Linuxで動作するデスクトップアプリケーションである
    • 世界中の利用者によるアプリケーション実行回数は月あたり約1,500万回規模である

QGISでベクタータイルを開く

  • QGISではLayer Menu -> Add Layer -> Add Vector Tile LayerからOSMベクタータイルを追加できる
  • 新しい接続では、スタイルURLに次の値を使う
  • ソースURLには次のMVTエンドポイントを指定する
  • スタイルシートは任意で、なくてもQGISがベクターデータを任意の色でレンダリングできる
  • QGISではアイコンレンダリングがずれる問題が確認されている
    • 他のマッピングツールでは、そのスタイルのスプライトが正常にレンダリングされる
    • QGISではアイコンがぼやけた黒いアイコンのように見える
    • 関連イシューはQGIS #59492にある

LeafmapとJupyter Notebookでのレンダリング

  • Jupyter Notebookの設定フォルダを作成してパスワードを設定したあと、サーバーを127.0.0.1で実行する
  • Notebookは実行した利用者の権限で動作し、現在のディレクトリと配下のファイルを公開する可能性があるため、空のフォルダで実行する方法を使う
  • Leafmapではleafmap.maplibreglを使い、スタイルURLにcolorful.jsonを指定してBurj Khalifa周辺をレンダリングする
  • LeafmapでのレンダリングではPOIアイコンが正しく表示される

MVTを分析可能なデータに変換する

  • Burj Khalifa付近のzoom level 14タイルを例に使う
  • おおよその座標[55.27, 25.2]をmorecantile tiles 14に入れて、タイル座標[10707, 7006, 14]を得る
  • その値で次のタイルをダウンロードする
  • 114KBのMVTファイルはmapbox_vector_tile.decodeと座標変換関数によって1.4MBのJSONファイルに変換される
  • 変換されたタイルのトップレベルキーには次のレイヤーが含まれる
    • addresses
    • bridges
    • buildings
    • ferries
    • land
    • ocean
    • pier_lines
    • pier_polygons
    • place_labels
    • pois
    • public_transport
    • sites
    • street_labels
    • street_polygons
    • streets
    • streets_labels_points
    • water_polygons
    • water_polygons_labels

POIレイヤーをDuckDBで見る

  • poisレイヤーを別のJSONファイルとして抽出したあと、DuckDBのST_READで開いて分析する
  • cuisine値があるPOIは67行として取得される
    • amenityの例にはrestaurant、fast_food、cafeが含まれる
    • cuisineの例にはfrench、greek、american、lebanese、coffee_shop、asian、persian、chicken、pizzaが含まれる
  • DuckDBのSUMMARIZE結果でPOIデータの充足度を確認できる
    • POIレコード全体は474件
    • name、name_de、name_enのnull比率はそれぞれ29.96%
    • amenityのnull比率は31.86%
    • cuisineのnull比率は85.86%
    • geomのnull比率は0.00%
  • approx_unique基準で、nameは258件、name_deは264件、name_enは245件、amenityは27件、cuisineは39件の値を持つ

tiles2columnsでバウンディングボックスを抽出する

  • 既存のosm_splitは、GeoFabrikが作成したOSM PBFファイルを名前付きGeoPackageファイルへ変換するツールだった
  • GeoFabrikのPBFファイルは、処理可能な時点では数日前のデータになっていることがある
  • 新しいOSMベクタータイルは、基礎データが編集された直後に更新される
  • tiles2columnsは、指定したバウンディングボックスのOSMタイルをダウンロードしてGeoPackageまたはParquetファイルへ変換するPythonベースのユーティリティである
  • ドバイ北部周辺のバウンディングボックスの例では、42枚のタイルをダウンロードし、数MB規模のGeoPackageファイル群を生成する
    • streets.gpkg: 6.8MB
    • buildings.gpkg: 6.2MB
    • pois.gpkg: 1.4MB
    • street_labels.gpkg: 1.4MB
    • land.gpkg: 744KB
  • 生成されたGeoPackageファイルはQGISプロジェクトにそのまま投入できる
  • ファイルはOSM MVTファイルで使われているキーごとに分かれており、各レイヤーを独立して識別・スタイリング・分析しやすい
  • 各ジオメトリの属性は個別のカラムに保存される
  • pois.gpkgで名前付きPOIを照会した例では6,329行が返り、Kiku、Fujiya Restaurant、Mövenpick Grand Al Bustan Dubai、McDonald'sのような名前が含まれる

関連記事

2件のコメント

 
GN⁺ 2024-11-20
Hacker Newsのコメント

  • ベクタータイルについては少し複雑な気持ちです。従来のラスタタイルが提供しているレベルの詳細を表示できる、スタイルとタイル生成器スキーマの組み合わせをまだ見つけられていません
    記事のスクリーンショットを見るだけでも違いは明らかです。1枚目には、像、店舗、劇場、展望台といった関心地点、橋として表示される道路、芝生と公園の色の違い、道路ごとの線の太さ、運動場、建物名・地区名、一方通行の矢印、建物の一部、階段、木など、多くの情報があります
    2枚目にはトロリー停留所が1つと道路名が1つある程度で、その道路名も正しくレンダリングされていません
    openmaptilesのスタイル、protomapsのデフォルトスタイル、mapboxのスタイルと、protomaps、openmaptiles、mapboxの生成器をかなり使ってきましたが、OSMのラスタタイルほど読みやすく、詳細情報が多いものはありませんでした
    ベクタースタイルは拡大・移動が滑らかで、スタイルの修正も簡単ですが、自分のデータの背景地図として使うのではなく、実際の地図データを見たい場合には物足りません
    おそらく計算リソースの制約が理由かもしれません。OSMラスタタイル並みの詳細を表示しようとすると、クライアント側とタイル生成側の両方でリソースを食い過ぎる可能性があります
    OpenStreetMapがまた一つ低コントラスト・低詳細の背景地図を提供するよりも、既存のラスタスタイルをより忠実に再現してくれるとよいと思いますし、今回公開されたベクタータイルのリリースが、より詳細なベクター地図を可能にしてくれることを願っています

    • 基本的にはその通りですが、見方は少し違うかもしれません。地図を提供する側にとって、ベクタータイルの主な利点は鮮明さやスタイルの柔軟性といった小さなメリットではなく、必要な計算量が大幅に減ることにあります
      最新のラスタタイル生成インフラを維持するのは、かなり大きな作業です
      以前、自転車旅行の計画用に非常に詳細なスタイルを長く開発していました: https://stevebennett.me/2015/01/14/cycletour-org-a-better-ma...
      何度もベクタータイルで再現しようとしましたが、サイズ制限に引っかからずに十分な詳細を入れるのはかなり難しく、標準のMapboxタイルには必要な情報がはるかに不足していました
      ただし、ベクタータイルにはラスタタイルにはない回避策もあります。たとえば、異なるレイヤーをオン・オフできる一方で、ラベルは下に何があるかを認識できるため、可読性を保てます
    • これまでは、そのタイルを活用するスタイルを豊かにすることよりも、継続的に更新されるベクタータイルを生成するソフトウェアに焦点が当たっていたように思います
    • OpenrailwayMapのフォークを作りました。元のサイトは https://www.openrailwaymap.org で、ベクタースタイルは https://openrailwaymap.fly.dev にあります
      スタイルは元のラスタタイルの見た目に近づけましたが、ベクター版にはインタラクション機能をはるかに多く追加しました
      スタイル・タイル設計の観点で興味深いのは、タイルがどこでどのようにレンダリングされるかによって、性能上のトレードオフが完全に変わることです。当然の話ではありますが、サーバーとクライアントで視覚的に何が可能かにも影響します
    • まったく同感です。道案内にはOpenStreetMapとGoogle Mapsを併用していますが、OSMだけを使いたくても、登録されている場所の数がGoogle Mapsほど多くありません
      それでもOSMの地図は表示される関心地点が多いので、ずっと使いやすいです。地図を見るだけで実際の場所の感覚が湧き、公園は公園らしく、病院は病院らしく見えます
      Google Mapsはグラフィックデザイナーの観点ではより良く見えるかもしれません。しかし方角を把握するには、たいてい道路や交差点の形を照合する必要があります。Google Mapsではどこも似たように見えます
    • まったく同じ考えです。openstreetmap.orgのデフォルトスタイルは個人的には純粋な幸福に近いのですが、ベクター地図をそのレベルにしようとかなり長く試してきたものの、使える結果は見つけられませんでした
      2分触ってみるだけで、詳細情報の欠落がすぐに分かるレベルです。本当に残念ですが、いつか誰かが解決してくれると楽観しています

  • オープンソースコミュニティがベクター地図タイル機能を作り上げていく過程を見るのは興味深かったです。2018年ごろにWeb GISの仕事をしていたとき、Google/Appleのストリーミング型ベクター地図は魔法のように見え、費用さえ許せばぜひ使いたいと思っていました
    ほどなくして中核技術がオープンソース化され、無料のホスティングソリューションまで登場しました。今ではLeafletの地図で優れたベクターレイヤーを無料で使えます。オープンソースに感謝です

    • OSMがここまで来るのにこれほど時間がかかったのは、少し意外です。基本的な技術要素は10年以上前からすでにありました
      無料の地図サービスに文句を言いたいわけではなく、サービスは素晴らしいですし、編集とデータ所有権により集中していることも理解しています。配信インフラは難しく高価です
      ただ、数年にわたってMapBoxの支配力が他の試みをどれほど妨げていたのかは気になります

  • OSM ベースの地図をホスティングする際、運用コストが下がるのか気になる。レンダリングに使う CPU が少なくて済み、ベクターは保存容量や帯域幅もあまり食わなさそうだから

    • イエスでもありノーでもある
      ノーである理由は、公式 OSM タイルレイヤーが Fastly から大きなスポンサー支援を受けているため。最後に確認したときは Fastly が €720k、AWS レンダリングが €40k だった
      イエスである理由は、技術的にはより少ないリソースで済むので AWS+Fastly への負荷も下がり、セルフホスティングもしやすくなるため
      以前詳しく読んだリスク評価では、OSM は「Fastly のスポンサー支援を失った場合、標準タイルレイヤーへのすべての第三者アクセスを遮断し、少数の Varnish サーバーだけを運用する可能性が高い」と書かれていた
      自分の理解では、ベクター化の主な動機はコスト削減というより、国際化の改善、クライアント側でレンダリング上の判断を可能にすること、そして多くの後続メリットを生む現代的なツール体系を構築することに近かった
      もっと新しい情報はあるはずで、関連資料は 1 と 2 にある
      1. https://operations.osmfoundation.org/2024/01/25/owg_budget.o...
      2. https://osmfoundation.org/wiki/Finances
    • ノーとも言える。ベクタータイルは、すでにかなり前からごく少ない手間でセルフホスティングしたり、誰かにホスティングを任せたりできたから
      ただし、ある程度の処理をクライアント側に移し、より重要な点として、多くのスタイル上の判断をクライアントに行わせられるという意味ではイエス。もちろん全部が可能というわけではない
      静的、または頻繁には更新されないベクタータイルは、さまざまなツールで OSM データから作成できる。現在もっとも人気があるのは https://github.com/systemed/tilemaker と https://github.com/onthegomap/planetiler
      実際に新しい点は、Paul が OSMF のために作った作業のおかげで、ベクタータイルを即時更新、つまり数分以内に更新できるようになったこと。これは OSM コントリビューターにとってフィードバック機構として重要であり、OSMF が現在ラスタタイルサービスを運用している主な理由でもある
      現時点では、ベクタータイルサービスの利用にどのような制限が付くかはまだ未定。ラスタタイルサービスと同様、第三者サービスと競合したり置き換えたりする意図はないが、ベクタータイルサービスは潜在的にはそうなり得る
    • はい、ベクタータイルはセルフホスティングがずっと簡単
      たとえば https://protomaps.com/、https://openmaptiles.org/、https://versatiles.org/ がある
    • openfreemap.org を作った者です。その通り。ベクタータイルは基本的に静的ファイルをホスティングするもので、サーバーは HTTPS 暗号化以外にやることがない
      gzip 圧縮もすでにタイル内で済んでいる

  • もう一つの問題は、ベクター版でアラビア語フォントが正しくレンダリングされないこと。右から左ではなく左から右にレンダリングされ、文字がつながらず分離して見える

    • ベクタータイルの要点は、レンダリングがローカルで行われ、タイルスキーマを除けば変更可能なスタイル設定によって制御されることにある
      そのため、見えている崩れはスタイル、またはローカルで内容をレンダリングするライブラリ側の問題
    • QGIS のベクタータイルレンダラーがどう動作するかは分からないが、GitHub のデモページなら MapLibre に RTL テキストプラグインを追加して、右から左に書くテキストを正しく処理させるのは簡単なはず: https://maplibre.org/maplibre-gl-js/docs/examples/mapbox-gl-...

  • あわせて見るとよさそうなもの: OpenFreeMap — 無料の OpenStreetMap ベクタータイルホスティング
    https://openfreemap.org/

    • OpenFreeMap が提供しないもの: 検索やジオコーディング、経路計算・ナビゲーション・道案内、静的画像生成、ラスタタイルホスティング、衛星画像ホスティング、標高照会、カスタムタイルやデータセットのホスティング
      https://github.com/hyperknot/openfreemap?tab=readme-ov-file#...
    • わあ、かなりよく洗練されているように見える
      これも同じベクター技術スタックをベースにしているのか、それとも完全に別の開発なのか気になる

  • 「画像はずっと鮮明になり、ラベル言語の切り替えも可能になる」という部分は、期待ほどにはうまくいかない気がする
    言語を変えたときにラベルサイズがそのまま保たれる保証はまったくなく、ラベルサイズは地図の配置と相互作用し、何を表示するかにも影響する
    ラベルが大きくなると、地図を覆いすぎたり互いに重なったりする可能性がある。ラベルが小さくなると、以前はスペース制約のため省略されていた都市が、新しくできた空きスペースになぜ表示されないのか、ユーザーが不思議に思うかもしれない

    • Google Maps でズームイン・ズームアウトすると都市名や道路名が消えるのが本当に嫌い。道路名や店名の中には特定のズーム段階でしか表示されず、さらに拡大または縮小すると見えなくなるものがある
      ただすべての道路名を表示すればいい。密になるのは気にしない。交差点に立って、名前のない地図を見ているのは役に立たない地図だ
    • いずれにせよ出発点はラベルの自動配置
      何年も使われてきたラスタタイルでも同じだった
    • 配置アルゴリズムが大きく変わると予想する理由はあるのか？

  • とても歓迎すべき新しい変化。より見やすい地図を期待している
    ただし「my workstation」セクションは少し不思議。記事の他の部分とはあまり関係がなさそうで、その後に扱う作業に高いシステム要件が必要というわけでもなさそう

  • 「画像はずっと鮮明になり、ラベル言語の切り替えも可能になる」というなら、たとえば都市の形状ベクター、正確にはポリゴンに、定義されている全言語の都市名メタデータを持たせて運ぶことになるのか？

    • 大都市はすでに複数言語の名前を含んでいる。たとえば Paris を見ればよい: https://www.openstreetmap.org/relation/71525
      言語切り替え機能の有用性は、当然ながら翻訳の有無に依存する。編集者に地名の翻訳をさらに追加するよう促すことにもなるかもしれない
    • 現在テストに使われているタイルスキーマである shortbread は複数言語をサポートしていないが、バグが整理されれば、作業している人たちはサポートしようとしていると理解している
      このような見え方の例は https://americanamap.org で見られる。OSM データを使っているが、この記事のタイルのようにほぼリアルタイムを目指しているわけではない
    • そうではないが、必要なテキストだけが入ったタイルを取得して、すでに持っているタイルにパッチを当てることはできる

  • これが、OSMAnd と OrganicMaps がついに力を合わせて究極の自由なオープンソース地図アプリを出すという意味ならいいのだが

    • 両アプリは主に、独自形式で前処理されたダウンロード用・オフライン用の地図データを使っている
      MVT 形式のベクタータイルはナビゲーションや検索にはまったく適していない。無理やり組み合わせて作れないという意味ではないが、かなり無茶がある
    • ひとつの究極の地図アプリというものはあり得ない。ユースケースが異なるためだ
      たとえば OSMAnd には、OSM に貢献する人たちにとって非常に有用な上級者向け機能が多いが、一般ユーザー向けアプリではインターフェースを煩雑にするだけかもしれない
    • 少なくとも両者が地図タイルを共有できるようになり、同じ地図でギガバイト単位の容量を重複して使わずに済むようになるとよい

  • https://marble.kde.org/ は9年前からストリーミングのベクター OSM レイヤーを独自実装して持っており、同様のものが他の OSM 地図アプリにも現れるのをかなり長い間待っていた
    Android の OSM アプリで国全体単位の大きな塊として数百メガバイトの地図をダウンロードするのは、常にストレージ容量の問題だった。ようやく標準が固まりつつあるのはとてもうれしく、複数のアプリで採用され、磨き込まれていくことを期待している。素晴らしい仕事だ

    • Android で Marble アプリを探してみたが、Play Store にも F-Droid にもない。Web サイトの Play Store リンクは 404 だ。放棄されたのか？