ROADSTOCK Ver 1.1.0 update / Google Geocoding APIを諦める

ROADSTOCKの「道路名を取得できない」不具合を修正しました。

経緯

この不具合は、過去に通ったことがない道路でないと露見しません。ROADSTOCKは、通信量削減のため、過去に経由したことがある座標付近を通過した場合、その座標に紐付いている道路名を使います。そのため、未体験の道路を通らない限り、今回の不具合には遭遇しません。2018年は遠出する機会が極めて少なく、未体験の道路を通る機会が全然無かったので気づかなかったのですが、房総半島ツーリングをしたところ道路名が軒並み”======”だったので、何だこりゃとなり、急遽修正することにしました。

原因

道路名取得には、Google Geocoding APIを用いて「逆ジオコーディング」をしていましたが、それが機能しなくなったことが原因です。

Google Geocoding APIは、httpsで所定のURLを引数付きで呼ぶことで利用します。この結果として帰ってくるJSON情報を解析し、そこから住所と道路名を取得します。従来は、このように呼び出していました。

https://maps.googleapis.com/maps/api/geocode/json?latlng=35.794507,139.790788&sensor=false

この呼び出しには特になんの制限もなく、自由に利用できました。同一IPアドレスからの呼び出し回数制限はありましたが、ROADSTOCKのように移動しながら呼び出す場合、キャリアの中継局が変われば自ずとIPアドレスも変わるため、結果的に制限なしのようなものでした。

それが2018年からGoogle社のポリシー変更により、API Keyの指定が必須となりました。そして、このAPI Keyの呼び出し回数が一定回数を超えると費用が発生するようになりました。

https://maps.googleapis.com/maps/api/geocode/json?latlng=35.794507,139.790788&key=XXXXXXXXXXXXXXXX

Googleも営利企業なので、損をするようなことはしません。儲けられるところで儲けるのは当たり前の話です。利用者が文句を言う筋合いはありません。ただ、使っていた側としては、何らかの対策を取らざるを得ません。

というわけで、本来はこの時点で対策しないといけなかったのですが、上記のように全然問題が露見しなかったので、上記の呼び出しは有効なままなのだと勝手に思い込んでいました(が、実際にはそうではありませんでした)。

そもそもGoogle Geocoding APIを使っていた理由

ROADSTOCKの道路名取得機能は、当初はAppleの(iOS用APIの)逆ジオコーディングAPIを使って作ろうとしていました。しかし、この逆ジオコーディングが「道路名取得」という観点では激しく馬鹿で、全然使いものになりませんでした。例えば、期待する値が「県道46号線」という座標で「XXX46(XXXは地域名)」という値を返してきます。XXXの値にはルールがないので、市だったり、町だったり、バラバラです。しかも「46」は全角という間抜けっぷり。

何らかのルールに基づいて「XXX」を「県道」に変換するという手段も考えましたが、これが県道なのか、国道なのかを判断する手段がないので、その時点でアウトです。Apple製APIの利用は諦めました。

ちなみに、ここまで馬鹿なのは日本だけで、米国(で取得されて、Web上に公開されているGPXデータを使ったテスト)で逆ジオコーディングする限り、あまり違和感はありません。他の地域がどうなのかは、もはや判断できないので追求していません。

次に考えたのはOpen Street Mapです。Open Street Mapは、企業が作った地図情報に縛られたくないという地球上の有志が作っている地図情報で、その機能として逆ジオコーディングAPIが提供されています(これも有志が作ったものですが)。

このAPIを試してみたところ、色々と問題がありました。まず、地図情報の有無自体、有志が登録しない限り存在しないため「こんな場所の情報もないの?」と言いたくなるような事態がそれなりに発生します。つまり、座標に対して道路名が取れない確率がそれなりに高い、ということです。「こんな場所の情報もないの?」と思ったのなら、自分が有志になって登録するしかないということです。

それ自体は仕方ないのですが、次の問題は、道路名が「路線番号(国道1号とか)」ではなく、名前や通称で登録されていることが極めて多いということです。例えば、横浜あたりでは国道1号は「第二京浜」、国道16号は「東京環状」として登録されています。

これは半ば趣味や好みの問題となりますが、個人的には路線番号を出してほしいです。通称は紙のリアル地図を見ても載っていないことが多く、後で振り返る時に困ります。

さらに付け加えると、区間によって「第二京浜」だったり「国道1号線」だったり、情報がバラバラです。こういうところがクリーニングされているのが業務用データなのですが、Open Street Mapはボランティア精神で成り立っているものであり、あるがままのデータを受け入れざるを得ません。Let it be。

というわけで、当初のROADSTOCK開発時は、Open Street Mapも利用を諦め、最も個人的に好ましい結果を返すGoogle Geocoding APIを選択しました。これは位置情報から日本であると判断した場合のみそうしており、それ以外の地域ではApple APIを利用しました。

Ver 1.1.0での対応

まず、Google Geocoding APIをそのまま利用できるかをシミュレーションしました。
Google Geocoding APIは、無償で利用できる呼び出し回数があり、それを超えない限りは私自身は損しません。
その回数がどれだけかというと、机上の想定では、日帰りツーリング(10時間程度)を10回実施したぐらいで無償利用の上限に達することがわかりました。上限を超えると、当月内の逆ジオコーディングリクエストは全て失敗し、道路名取得できないということになります。

私がGoogleにお金を払えば利用できますが、その支出に対して何らかのメリットがあるかというと、率直に言って何もありません。仮にROADSTOCKのユーザ数が膨大で、月あたりの広告収入が100万円とかいう状態であれば支払っても構いませんが、そのような状況ではありませんので、私にはこの支払いをする意思はありません。

こうなると、選択肢はOpen Street Mapしか残っていません。過去に色々と試行錯誤したので、問題があるということはわかった上で使うしかありません。

率直に言って消去法ではあるのですが、Open Street Mapの活動に参加している有志の方々に感謝しつつ、使わせていただくことにしました。

そのため、Ver 1.1.0 では、道路名がそれなりに取得できるようになっているはずです。但し、これまでとは少々違った道路名になっていると思います。

なお、Open Street Mapは、Google Geocoding APIに対して、1つアドバンテージがあります。Google Geocoding APIは、高速道路、国道、県道の道路名は返しますが、それ以下の市道、農道、林道等は返せません。それに対し、Open Street Mapはこれらの情報も持っている可能性が高いです。ある程度ツーリングをする方の中には農道や林道を積極的に選択する方も居ると思いますが、そのような方にはOpen Street Mapはベターな選択となります。ただ、一日中その手の道を走っているかというと、おそらくそんなこともないので、痛し痒しということになるのではないかと思います。

Open Street Mapベースの逆ジオコーディング

Open Street Map自体は「座標と、その座標における各種情報の組み合わせ」ですが、それを用いて逆ジオコーディングをするための仕組み「Nominatim」を用いて、座標情報から道路名を取得しています。

以前の開発検証時は、自力でNominatimのサービスを呼び出してJSONを解析していましたが、Ver 1.1.0の開発にあたっては、公開されているライブラリ「SwiftLocation」を利用することにしました。今後どう転ぶかわからないので、あまりこの処理を自力でガリガリ組みたくなかったためです。

実はこのライブラリは、開発時点での最新版(Ver 3.2)では、バックグラウンドで常に位置情報を取得させるための「pausesLocationUpdatesAutomatically」に対応できていないのですが、pull requestで対処されているため、それを利用しました。pausesLocationUpdatesAutomaticallyの設定ができないと、Google Map等のナビを全面に出しっぱなしにしてROADSTOCKをバックグラウンドで放置していると、いつの間にかロギングを停止している可能性が高まります。これを設定できないというのは致命的な問題になります。

今後の対応

今後の対応ですが、主要地方道(いわゆる県道)に関しては、Wikipediaあたりで路線番号と道路名の関係性が記載されているので、これを用いて、Open Street Mapが取得した道路名の変換をできないかと考えています。これができれば、従来の(Google Geocoding API利用時の)結果と同じものが得られると考えられます。なお、これは妄想レベルの話で、実現することをお約束するものではありません。

なお、例えば「第二京浜→国道1号」のように、その地域で一般的に呼ばれている通称から路線名への変換については、Wikipediaのような整理済みの情報データベースが存在していないため、対応する予定はありません(私にはそれを調べてまとめ上げることに対するメリットも余力もありません)。

Apple製のAPIが真っ当な情報を返すのであれば、それを使うのがベターですが、今後どうなるかは判らないので何とも言えません。

「ROADSTOCK Ver 1.1.0 update / Google Geocoding APIを諦める」への1件のフィードバック

  1. ピンバック: K1100RS 裏磐梯キャンプツーリング | sabitori.com

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です