こんにちは。truestarの藤です。
今回はジオコーディングAPIを用いて住所データを加工してみたいと思います。
はじめに
使用するのはインクリメントＰ社のジオコーディングAPI（有償サービス）です。
なぜ、無償であるGoogleのジオコーディングを使わないのか、といったご指摘も良くいただくのですが、弊社のようにBIでの可視化や空間データ分析を目的とする場合、Googleのサービスは利用規約に引っかかります。（2021年5月末時点）
No Use With Non-Google Maps. To avoid quality issues and/or brand confusion, Customer will not use the Google Maps Core Services with or near a non-Google Map in a Customer Application. For example, Customer will not (i) display or use Places content on a non-Google map, (ii) display Street View imagery and non-Google maps on the same screen, or (iii) link a Google Map to non-Google Maps content or a non-Google map.
ご存じでない方が多いのですが、利用規約3.2.3(e)にて、Google Map以外での使用を認めていません…
他の無償ジオコーディングもデータ取得や用途に制限があり、相当データ量が少ない場合を除き、全量の取得に時間がかかるなど、一般的な分析用途では厳しいものが多いです。したがって、通常の分析案件では何らかの有償サービスを使う必要性が高いと思います。
過去にも
と、インクリメントPさんのMapFan APIを用いたAlteryxのジオコーディングマクロのご紹介をしましたが、今回はマクロではなくその中身を解説していきます。
ワークフロー全体は以下のような形です。
データの下準備（API前）
ジオコーディングを行うためにはAPIに対して必要な情報を投げる必要がある訳ですが、その前に下準備が必要です。
まず、今回入力値として使うのはインターネットで公開されているチェーン店舗住所です。ランダムサンプリングしたものを使っており、必ずしも正規化されていません。
この住所にジオコーディングを行います。
続いて、APIを叩く時の開発には欠かせない（と私は思っている）、分岐を作ります。
大量のデータを毎回流してしまうと、データの取得に時間がかかりますし、有償サービスならば課金が増えます。またサーバーにも負荷がかかりますので、基本的に必要な時以外はデータを絞って開発していきます。
【分岐】ツールは【分岐終了】ツールとセットで使います。
設定は『右に分岐』のチェックボックスしかありません。
この場合は、開発時はチェックを外し、Lにデータを流します。その際【サンプリング】ツールでデータを100件に絞っています。
開発の要所で『右に分岐』させて、全量データ（またはそれに近い）でそのワークフローが機能するかを適宜チェックしながら構築します。完成後は常に『右に分岐』のままです。
次も無駄にAPIを叩くことを回避するための処理として、住所データの重複を除きます。
まず【レコードID】ツールで通し番号を振り、【ユニーク】ツールで住所の重複を除外します。
重複のないデータでAPIを叩き、必要な加工をした上で、後ほど元の住所リストに戻すことになります。
次はAPIを叩くために送るパラメータを作るステップです。
このステップでは今回使用するAPIの仕様に合わせて、必要な処理を埋め込んでいます。
このジオコーディングAPIの仕様では、一度に処理できる住所は50件まで、APIを呼び出す間隔は最低1秒空ける必要がある、といった制限があります。
これらの条件に合った自動化フローを組まないと、一度のワークフローの実行では全てのデータ取得ができません。
ユニーク化された後、改めて【レコードID】を振り、【フォーミュラ】ツールを用いて50件ずつグループ化するための整数を持ちます。
次に、50件単位で住所を1つのデータに結合します。
APIのリクエスト時には当然URLとAPIのKeyが必要になります。Key（x-api-key）はインクリメントP社との契約後に提供されます。
【テキスト入力】ツールに基準となるURL（domain）とKey（x-api-key）を入力し、【フィールド付加】ツールで各レコードにつなぎます。
実際に必要なURLを【フォーミュラ】ツールで作ります。x-api-keyは【ダウンロード】ツールで設定するのでここでは組み込みません。
【スロットル】ツールを使うと、各レコードの処理時間をコントロールできます。この場合12回/分なので5秒ごとにAPIを叩くことができるようになります。
こういった痒い所に手が届くツールが最初からあるのがAlteryxの良さですね。
【ダウンロード】ツールでは、基本設定でURLを選択し、ヘッダーでx-api-keyをチェックすればOKです。
APIIからの出力は『DownloadData』カラムの1つのセルに、50件の住所に対する結果がぎっしり詰まっています。
これを分解していく必要があります。
JSONデータの分解（API後）
このステップでJSONデータを人間が使いやすいテーブル形式に変換します。
最初の【セレクト】でカラムを絞り、【JSONパース】で『DownloadData』を分解します。
『DownloadData』カラムの2レコードが2204レコードの分解されました。JSONの1セルに1000件以上の情報が含まれていた訳です。JSONってすごいですね。
今回使いたい情報は、JSON_Nameのfeatures.X.XXXXなので、【フィルター】で頭にfeaturesが付くデータに絞り、【フォーミュラ】で正規表現を使って分解します。
『JSON_Name』を『ID』と『Properties』に分解しました。レコード1から21がID=0になっていますが、これは1つのインプット住所に対して、21の情報を得ていることを意味しています。
正規表現に関しては、ここでは細かく取り扱いませんが、確か昨年のJapan Alteryx User Groupで以下の2サイトが紹介されていましたのでそのまま共有します。苦手な方は参考にしてみてください。
【クロスタブ】ツールで縦持ちになっているデータを横持ちに変更します。
【結合】で、ユニーク化する前のデータと住所でJoinします。JSONのアウトプットでは『properties_query』が該当します。
その後の【ユニオン】は基本的になくても問題ありません。処理のエラーが無い限り【結合】からはJの出力からしかデータが出てこないはずです。
【ソート】で元データの並び順に変更し、【セレクト】で必要なカラムに絞って、カラムの並びを整えてこのステップは完了です。
汎用的なテーブルが出来上がりました。
インクリメントPさんのジオコーディングだと、住所が分解された上に読み仮名も付与されます。
業務システムによっては、読み仮名の入力も必須になっていることもありますが、そういった作業を大幅に省力化可能ですね。
データプレップでより使いやすくする
最後のステップです。
ここは、その先の可視化やデータ分析のための加工ですので、目的・用途によって作りは変わります。
ここでは例として、空のデータをNull化、住所の表記を調整、緯度経度をポイント情報化、などを施しました。
この【フォーミュラ】は住所の表記を調整するものです。
1丁目 1-1を1-1-1のように、住所を少しでも短くしたい、などと言った細かい業務ニーズに合わせた加工です。例外処理の対応など、意外と難しいんですよね・・・こういうの。
プレップ作業ではこういう地味な依頼がボディブローのように効いてきます。
最後は【閲覧】ツールになっていますが、ここを【データ出力】に変更すれば、Excel、CSV、HYPER形式や、RedshiftやSnowflakeなど、使いやすい形式・場所に出力できますね。
おわりに
前回のブログ
Alteryx で e-stat API からデータを取得する
でも書きましたが、APIからデータ取得って結構難しいんです・・・。
データのAPIは間違いなく便利な機能ですが、『誰でも使いやすく』と言ったものではありません。
『データの民主化』は、このようなデータプレップ作業が無くても、誰でも使いやすくキレイな形でデータが供給されるような状況が整っている状態を意味すると勝手に思っていますが、truestarでは『データ分析の民主化』や『データの民主化』のラストワンマイルを埋めるべく、引き続き様々なサービスを展開していきます。
ということで、APIからのデータプレップ（取得や加工）にお悩みの方は、是非こちらからtruestarまでお問い合わせください。（笑）
それではまた。
