「Pythonを使用した最も近いバーを見つけるための近接解析」

『近接解析による最も近いバーの検索』をPythonで実現する方法

空間データ処理についてのいくつかの言葉

プレビュー画像(著者提供)

免責事項:この記事では、オープンソースのライブラリestatyを使用して、すべてのアプローチをデモンストレーションいたします。このライブラリは、私たちの仕事で使用しているアルゴリズムを他の開発者に利用できるツールとして形式化するという希望から生まれたものです。言い換えれば、この記事はライブラリのメンテナーによって書かれたものです。

今日は、オープンソースのPythonライブラリを使用した空間データ処理のトピックについて話し続けたいと思います。すでに、Open Street MapとLandsatオープンデータを組み合わせて、緑地域のエリアを確認する方法について説明しました。

次に、もう1つのタイプの分析である近接性分析について考えましょう。公園、病院、幼稚園などの便利なオブジェクトの利用可否(または利便性)(図1)を考えてみましょう。

図1. 近接性分析のアプローチを示した図(ここでは例えば理美容サロンのこととします)(著者の画像)

近接性分析について少し

この物語を短い文献レビューから始めましょう。私が気に入っている記事は、会員限定のストーリーですが、「データサイエンティストが知っておくべき場所分析のユースケース」です。この記事は、読者を比較的簡単に地理情報解析の概要に導いてくれます。

また、「公園へのアクセスを測定するための距離コスト表面の作成」や「成長するユタ州:ユタ州の住民の医療施設への近接性分析」といった記事も、エンジニアがこのような分析を行うためにどのような特性を計算できるかを非常に明確に示しています。このトピックは非常に人気があり、多くの学術論文や実用的なアプリケーションが開発されていますので、参加しましょう。

使用しているライブラリ

さあ、より具体的な話に移りましょう:この近接性分析に使用できるツールについて(地理情報システム(QGISやArcGIS)や製品のエンドユーザーとしてのプロプライエタリサービスに加えて)。

私たち開発者は、集計されたデータではなく、便利なライブラリやサービス(できればオープンソース)を使って生の値を分析したいと考えています。しかし、私たちに適したツールは見つかりませんでしたので、Pythonで書かれた独自のオープンソースライブラリestatyを開発し、使用しています。この記事を読んだ後に、ドキュメントページをご覧いただくことができます:

このライブラリを基に、私たちはユースケースを構築しています。これらの例に基づいて、不動産管理者が分析を行うのを支援するマイクロサービスを開発しました。ただし、これらのスクリプトはユースケースとして組織されており、ライブラリを使用したい人々に利用できます。

estatyはさまざまなデータソースを使用して計算を行うことができますが、オープンな例(本当にオープンなものを保つため)はOpenStreetMapデータに基づいています。この論文では、比較的迅速な付随見積もりを行う方法を示すと同時に、必要に応じて新しいデータソースにアプローチを拡張する方法を示したいと思います。

分析(私たちができること)

まず、以下のコマンドを使用してライブラリをインストールします。

pip install estaty==0.1.0

または、poetryを使用している場合は:

poetry add estaty==0.1.0

バージョン0.1.0の使用準備ができました。

実装を始めましょう。次のアドレスに対して近接分析を提供します:「ベルリン、ノイシュテディシェ キルヒシュトラーセ 4–7」- 座標 {latitude: 52.5171411, longitude: 13.3857187}。このオブジェクトの近隣を2キロメートルの半径で分析します。

最も近いバーまでの所要時間を調べるために(OSMに基づくものであることはここで言及しておく価値があります)、以下のコードを書いて実行しましょう:

ここでは、物件の分析のための処理パイプラインを構築します。パイプラインは、データ上の順次変換から成るグラフのようになります:

図2. OpenStreetMapデータを使用してバーまでのルートの距離を計算するための空間データ処理パイプライン(著者による画像)

「裏側」で何が起こっているかをより詳しく見てみましょう。まず、estatyのアーキテクチャは5つの抽象レイヤーに基づいて構築されていることから始めましょう(上記のパイプラインの場合、ノードのタイプは3つだけ使用されています):

  • データソース — 必要なソースからデータを読み込み、データを共通の基準(ベクトルとラスター)にもっていきます。ソースが何であろうと、このノードの出力は2つの可能なバリエーションのみであり、それによってさらなる処理の統一が可能になります。
  • プリプロセッサ — ベクトルまたはラスターデータの前処理、例えば新しい座標基準系(CRS)の割り当てなど。
  • マージャー — データを必要な方法で結合します。組み合わせ可能なもの:ベクトルデータとベクトルデータ、ラスターとラスター、ベクトルデータとラスターデータと。
  • アナライザー — ラスターオブジェクトやベクトルオブジェクト上の単純な原子変換を使用して、エリアマッチングやパスファインディングなどの分析を実行するライブラリのコアです。
  • レポート — ユーザーフレンドリーな形式でレポートを生成するオプションの最終分析モジュールです。

これらのノードを特定の方法で組み合わせることで、元のデータの処理方法を変更せずにデータ分析のためのさまざまなパイプラインを構築することができます(アニメーション1を参照)。

アニメーション1. パイプラインの解析の準備時にライブラリの柔軟性(著者によるアニメーション)

したがって、図2は分析に3つのノードのみが使用されていることを示しています。その結果、私たちは興味のあるオブジェクトへのルートを持つgeopandas GeoDataFrame(ジオメトリオブジェクトのテーブル)を取得します。この場合はバーへのルートです。なお、結果の可視化は次のようになります:

図3. アルゴリズムによって計算されたバーへのルートと距離(著者による画像)

取得した一連の線形オブジェクトには自由に使う権利があります。例えば、最も近いバーまでの距離を求めるか、サンプルから平均値をリクエストすることができます(コード内で行われていることです):

  • 最小の長さ:308.93m
  • 平均の長さ:2306.49m

大都市の中心部にあるバーの場所についての真の専門家として、解析エリアのバーの数は実際にはもっと多い可能性があります。しかし、最初にOSMデータに基づいて解析することに合意しましたので…。

パイプライン自体は、解析が行われるデータのソースに依存しません。これは、ライブラリモジュールの弱い相互結合性によって保証されています。まず、DataSourceノードから始めましょう。このノードには、データの変換機構が組み込まれています(たとえば、ここではベクトルデータはgeopandas GeoDataFrame形式であり、常にポイント、ライン、またはポリゴンのいずれかの形式に変換されます)。次に、データに適切なメトリックプロジェクションを自動的に決定するプリプロセッサが続きます。プリプロセッサにとって重要なのは、データがノードのDataSourceから来ることであり、それ以外のことは前のノードで処理する必要があります。そして、シンプルなパイプラインは、ジオメトリオブジェクト(領域、線、またはポイントであっても関係ありません)上で操作する解析ブロックによって完了します。

したがって、OSMから抽出する他のデータカテゴリについても同じ計算を行うことができます(もちろん、リストはOSMに限定されません)。たとえば、学校、公園、水域、公衆トイレ、廃棄物処理容器、警察署などの近接分析を行うことができます。オブジェクトのタイプ(タグによって定義されるオブジェクトのタイプについては、ウィキページのマップの特徴またはデータソースに関する文書を参照してください)に対して:

図5. 学校、公園、水域、廃棄物処理容器、警察署の近接分析(作者による画像)

アプローチのスケーリング方法

社会データ、自然物や人工構造物など、どのような性質の空間データでも分析できることを述べました。ソースコードをさらに詳しく見てみましょう。図から分かるように、距離の計算は通常歩いてバーに行くために道路を考慮した経路上で行われます。したがって、「距離」の解析には、OSMからの経路を利用した道路グラフ上のルートの検索が含まれます(以下の記事に依存しました:OSMnx: Python for Street Networksを強くお勧めします)。

図6. 最適なルートを検索するために使用される歩行路のグラフ(作者による画像)

ここでは、グラフは地理的に参照される(緯度と経度の属性を持つ)ノードとエッジです。オブジェクトAからオブジェクトBへの最短ルートを見つけるためには、次の3つのステップを踏む必要があります:

  1. グラフ上でオブジェクトAに最も近いノードを見つける(ノード1とします)
  2. グラフ上でオブジェクトBに最も近いノードを見つける(ノード2とします)
  3. グラフトラバーサルアルゴリズムを使用して、ノード1からノード2への最適なルートを検索する

距離を求める場合、ノード1からノード2までのルートの長さとオブジェクトAからノード1までの距離、およびオブジェクトBからノード2までの距離を合計する必要があります。最後の2つの要素は直線で計算することができますが、ネットワークのノードはかなり密集しています。しかし、ここには難しさがあります。オブジェクトAとBがポイントの場合、それに最も近いノードを見つけるのは比較的簡単です(ポイント間の距離を計算する)。たとえばオブジェクトAのジオメトリが領域である場合、ポリゴンに対して「最も近い」ノードを探す必要があります。線状オブジェクトの場合はどうすれば良いかも問題を解決する必要があります

では、「異なるタイプのグラフノードからベクトルオブジェクトへの距離を統一的な方法で計算するにはどうすれば良いか」という質問に答えましょう。この目的のために、ライブラリは計算を開始する前にオブジェクトをポイントタイプに変換します(ポイント間の距離を計算するのは非常に簡単です)。私たちはこのような変換を表現と呼んでいます(図7参照)。

図7. ベクトルオブジェクトの表現方法(著者による画像)

つまり、3つのアルゴリズムを書いたりメンテナンスしたりする代わりに、1つのアルゴリズム(ポイントへの経路の検索)を書いて、すべての初期データのタイプを1つに減らします。それらを1つのタイプに減らす方法は曖昧な問題です。ただし、都市部での計算や特に大きなオブジェクト(公園など)の場合、中心地にいるということではなく、アスファルトの道から初めて心地良い土の公園の闇に足を踏み入れるときに公園に到着したとみなすとします。

ですので、私たちは、解析対象(経路が構築される元になるもの)に対してポリゴンまたは線形オブジェクトの最も近い点を見つけるアプローチを使用することにしました。そして、この点を最終的な目的地ノードとみなし、グラフを介したさらなる経路を構築します。

より高度な解析

バーへのルートだけでは誰も感動させることはできません。では、課題を複雑にしましょう。例えば、オークの木のある公園までの平均歩行距離を計算したいとします(バーで遊んだ後に木のある公園を散歩して楽しんだりするのが好きです)。そのために、2つのソースからデータを組み合わせてみましょう:

  • GBIF(グローバル生物多様性情報施設)からベクトルデータをダウンロードします(関連情報はこちらを参照、2023年10月20日現在の情報です)
  • OpenStreetMap – ライブラリ内のデータダウンロードのネイティブ統合

GBIFデータは、特定の植物や動物の種が見つかった場所を示すポイントジオメトリを持つベクトルレイヤです。この場合、クヌギ(またはラテン語でQuercus robur)に興味があります。以下は、公園のポリゴンの上にオークのポイントレイヤをオーバーレイしたときのデータの例です:

図8. OSM公園データとGBIFデータを組み合わせてカシの森公園への経路を計算する(著者による画像)

分析のコードはこちらです:

重要な注意点として、ポイントは公園のポリゴン内に完全に含まれる必要はありません。私たちはさまざまなソースからデータを組み合わせているため、若干の違いが生じる可能性があります。したがって、10メートルのバッファを設定し、結果を見ます(図9) – GBIFデータによれば、バッファポリゴンと公園ポリゴンが交差している場合、公園にはカシの木があるとみなします。

図9. カシの木のある公園への経路と計算された距離(著者による画像)

関連性について少し詳しく

分析のトピックは需要があり明らかです。したがって、たとえば、多くのソースコードソリューションでルーティングの機能が利用可能です(この記事を準備している間に興味深いノートブック「Exploring routing tools for calculating paths for a set of origin-destination pairs」に出会いました)。また、Googleマップや地図に関連するサービスなど、一般的なユーザーサービスにもルーティング機能があります。近接分析についても実装されたソリューションが多数あります。たとえば、pandanaというツールを挙げることができます。

これらのツールは確かに便利ですが、アプリケーションの例で使用するにはいくつかの補助コードを書く必要があります。私たちは、自分たちのチームのための便利なツールを作成し、コミュニティと私たちの発見を共有したいと考えています。この記事で紹介するアプローチでは、データソースに依存しないアプローチと柔軟なデータの組み合わせの方法に言及することができます。コメントや提案をお待ちしております。

有用なリンク:

この投稿で使用されるデータセット(およびライセンス):

  1. 地図データの著作権はOpenStreetMapコントリビュータに帰属し、https://www.openstreetmap.orgから入手できます。ライセンス – Open Data Commons Open Database License リンクは2023年10月25日時点の最新です。
  2. GBIF.org(2023年10月20日)GBIF Occurrence Download https://doi.org/10.15468/dl.f487j5 ライセンス – Attribution-NonCommercial 4.0 Internationalリンクは2023年10月25日時点の最新です。

OpenStreetMapデータを使用した近接度分析などのストーリーは、Mikhail SarafanovWiredhutチームによって発表されました。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!

Share:

Was this article helpful?

93 out of 132 found this helpful

Discover more