こんにちは。藤です。

昨年末の Alteryx User Group in Tokyo Advent Calendar 2018 でインクリメントP社の提供する MapFan API を用いたジオコーディングマクロ（無償）を公開しました。

Alteryx でジオコーディング 2018

インクリメントP　MapFan API

しかし、その後、不具合がいくつか見つかったり、若干使いづらい部分も残っていたため、大幅に改修したものをアップしてもらいました。

Alteryx Gallery – MapFan GeoCoder

この後、長くなるので結論を先に言うと、

マッチング精度

と

使い勝手

が格段に向上しました！

詳しく見ていきます。

一番大きい部分としては、取り込んだ住所データが MapFan API内の住所データとうまくマッチングしない場合に、API からは複数の候補を取得しているのですが、マクロでは一番最初の候補を取得していたため、誤った結果を出力することがありました。

一意にマッチングしているかどうかと複数マッチングしたかどうかの判別と、複数マッチングの結果は別のフローで出力し、元データ側の住所のクレンジングにつながるようにしました。

また、MapFan API での住所のマッチングにはマッチング精度というものがありますので、ジオコーディングのマッチング状況を

「都道府県レベル」
「市区町村レベル」
「町丁目レベル」
「番地レベル」
「号レベル」

で判別できるよう出力してあります。

いずれにせよ、フローを回して細かい点を見てみましょう。
最終形はこんな感じです。

使用するデータは例によって国土数値情報のオープンデータを使います。
今回は神奈川県の『警察署』データです。

国土数値情報　警察署データ

警察署データは SHP ファイルで最初からポイントデータを持っています。つまり、このままでも緯度経度情報は取得できます。
今回は、ジオコーディングマクロで取得した緯度経度の精度検証も同時に行うため、あえて SHP ファイルをインプットデータに選びました。

次のステップは Detour （迂回）です。MapFan API の無償サービスは月間5000pvです。いずれにせよ件数が多いと、データ取得の時間もかかりますので、ワークフロー構築段階では、[Detour] ツールを使用して、少量のデータを回しながら進める形が非常に効率的です。

このフローでは、[Detour] ツールのチェックボックスにチェックを入れると、最初の10レコードのみが処理に回る作りになっています。

続いて [Select] ツールでリネームします。
SHP ファイルはカラム名に日本語を利用できません。なので、多くの場合、わかりにくい名称がついています。そのままにすると、後続の処理で使い勝手が悪いので早めにリネームしておきます。

次はお待ちかねの [MapFan API] マクロです。

MapFan ID の事前取得を行い、そのキーを入力し、今回は『住所から緯度経度へ』を選択し、住所データである『警察施設所在地』を選択します。

679件の元データに対して、1分弱で Run が完了しました。
実際のアウトプットを見てみましょう。

『S』と書いてあるほうが一意にコーディングできたものを集めたレコードです。
それ以外は画像の赤枠のように、APIから取得される住所・緯度・経度にはNullが入っています。つまり、インプット時とアウトプット時のレコード数は変わりません。

しかし、赤枠のレコードは、『条町丁目レベル』でのマッチング結果として、4つの候補が取得できています。

※『条町丁目レベル』はインクリメントP社の仕様書の表記に沿っていますが『町丁目レベル』と同義です。ちなみに北海道などに『条丁目』が存在するためにこの表記になっていると考えられます。


複数マッチングの結果は『M』のほうに出力されています。

実際に赤枠のレコードで何が起こったかというと
元データの住所は『横浜市鶴見区潮田3-142-1』ですが、MapFan側のデータベースには『横浜市鶴見区潮田町1』 『横浜市鶴見区潮田町2』『横浜市鶴見区潮田町3』『横浜市鶴見区潮田町4』 が存在し、どちらが正解か判別できないので複数の候補が得られた、という訳です。
実は正確な住所は『潮田3-142-1』ではなく『潮田町3-142-1』です。
グーグルで調べると補正して出力されます。

このあたりの補正は現時点での MapFan API ではさすがに対応していないようです。

最後は精度検証のロジックです。
MapFan API から取得した緯度経度と、元データの緯度経度の直線距離を測り、ズレがあるのかどうか、また何故それが発生しているのか検証します。

最初に [Create Point] ツールを使います。

[Select] でカラム名をわかりやすく変更します。

[Distance] で二点間の距離を測ります。

[Sort] で降順に降順に並べ替えます。

[Brawse] で結果を見てみます。

最も離れているものは 4km 以上でした…

このレコードは、マッチングは一意に定まって成功扱いですが、精度が市区町村レベルどまりになっています。
原因は住所に含まれる『六ッ川』の『ッ』のようで、MapFan側は大文字の『ツ』で管理しているようで、弾かれてしまいました。元データのクレンジングが必要そうです。

他の結果も見てみます。

2番目は、元データの住所が戸塚区になっていますが、港南区の誤りでした。
つまり元データの住所が存在しないため、戸塚区までしかマッチングせず、結果に大きな乖離が生じました。

3番目は1番目と同じ『六ッ川』なので飛ばします。

4番目は、号レベルでマッチングしているにもかかわらず、距離が2km以上離れています。結論から言うと、元データの Point データが間違っていました。

グーグル先生に聞いてみます。

ということで元データの Point データは全然違うところを指しています。
ちなみに MapFan API のポイントは正しく交番の住所を取得できていました。
7行目の鶴見区北寺尾のレコードも、11行目の鶴見区駒岡のレコードも元データが間違っています…オープンデータとは言え、もう少し何とかしてもらいたいものですが。

いずれにせよ、MapFan API からは正しい位置が返ってきていました。

また、番地レベルや条町丁目レベルでのマッチングの場合、下のレベルのズレは普通に生じます。元データも MapFan API もどちらも正しいデータですが、マッチングした領域が広域のためにズレが生じます。

実際の地図を見ると

となっています。
元データはポイントデータなので、正しく『横浜水上警察署』を指しています。
一方、MapFan API 側は『横浜市中区海岸通1丁目』でジオコーディングをしているため、陸地部の中心に近い領域を代表点として取得しています。

誤差をどの程度許容できるかは、ジオデータを活用する目的に依存します。
大型の商業施設の立地選定の場合は数百mレベルでも許容できるでしょうし、コンビニなどの小規模店舗の商圏であれば、数十mレベルには抑えたいかもしれません。

ジオデータの利用目的に沿ってマッチング精度を設定し、マッチングが成功しても、マッチング精度が粗いものはローデータのクレンジング対象とすることで、より精度の高いジオコーディングが可能になります。

今回のジオコーディングでは、679件中、複数マッチングとして弾かれたものが11件、100m以上乖離したものが54件となりました。元データがそもそも間違っているものを含めても9割以上は高精度でコーディングできたようです。

このレベルであれば、様々なシーンで活用できそうです。

それではまた！