PlaceIDとは
Google Mapsの PlaceID は、建物や店舗など「場所」に付与された一意なID。
他のデータとは少し毛色の違う下記のような特徴がある。
- ユーザー側のシステムに無期限でキャッシュできる
- キャッシュのリフレッシュのためのAPI呼び出しは無料
その他の特徴は PlaceIDのドキュメント 参照。
簡単にまとめると、
- IDの長さは可変
- PlaceIDで場所を一意に特定できる
- 1つの場所に複数のPlaceIDが付くこともある
- PlaceIDは変わることもある
PlaceIDのサンプルをいくつか。
サンプルだと27〜114文字だが、最大長は分からない。
ChIJgUbEo8cfqokR5lP9_Wh_DaM
GhIJQWDl0CIeQUARxks3icF8U8A
EicxMyBNYXJrZXQgU3QsIFdpbG1pbmd0b24sIE5DIDI4NDAxLCBVU0EiGhIYChQKEgnRTo6ixx-qiRHo_bbmkCm7ZRAN
EicxMyBNYXJrZXQgU3QsIFdpbG1pbmd0b24sIE5DIDI4NDAxLCBVU0E
IhoSGAoUChIJ0U6OoscfqokR6P225pApu2UQDQ
ElMxNjIsIExhbmUgTnVtYmVyIDcsIEJsb2NrIEgsIE5lYiBTYXJhaSwgU2FpbmlrIEZhcm0sIE5ldyBEZWxoaSwgRGVsaGkgMTEwMDYyLCBJbmRpYQ
コンテンツのキャッシュと規約
Google Maps APIで取得したデータはユーザー側でキャッシュできるのか。
規約上は原則としてコンテンツのキャッシュは禁止されている。
一時的なキャッシュとして30日間保持することが許可されている項目もある。
Google Maps Platform Terms of Service 3.2.3(b) No Caching
ただし、PlaceIDはサービス固有の規約でキャッシュできることになっている。
Google Maps Platform Service Specific Terms 5.4 Caching
サービス固有の規約上はPlaces API Policiesに従うようになっており、そこにも無期限にキャッシュを保持できる旨が記載されている。
Pre-Fetching, Caching, or Storage of Content
キャッシュしたPlaceIDの用途
キャッシュして何に使うのか。
当然Google Mapsの色々なAPIを横断しても使える。
1度目のリクエストでは検索して、2度目以降はPlaceIDで引っ張ってくるというのも一般的に多そう。
あと、自社のシステムで保持しているデータとGoogle Mapsの場所データをリンクさせたり。
キャッシュ時の考慮事項
キャッシュ全般に言えることだが、オリジナルのデータと整合性が取れなくなる。
その対策というか考慮事項についてはここに書いてあった。
Save place IDs for later use
これもまとめておくと、
-
NOT_FOUNDが返ってくることがある - PlaceIDは定期的にリフレッシュするのがベストプラクティス
- PlaceIDのリフレッシュに使うAPIは何回呼び出しても無料
- リフレッシュするためには、Place Detailsリクエストで
fieldsパラメーターにPlaceIDだけ指定する - リフレッシュ時に
NOT_FOUNDが返ってくることがある（え - 1つの方法として、PlaceIDを取得したときのリクエストを保持しておく方法がある（え
- ただし、そのリクエストは有料（ええ
PlaceIDの更新事由
その他に、どういった理由でPlaceIDが変わるのかも書いてあった。
- 移転
- 閉店
- Googleの都合（え
PlaceIDの中には変わりやすい、もしくは NOT_FOUND を返しやすい場所もあるらしい。
よく分からなかったので原文のまま引用・・・
- Street addresses that do not exist in Google Maps as precise addresses, but are inferred from a range of addresses
- Segments of a long route, where the request also specifies a city or locality
- 交差点(これは分かった)
- Places with an address component of type subpremise
こういった場所はPlaceIDが長くなる傾向にあるっぽい。
サンプルに挙げたこの長いIDがそれ。
ElMxNjIsIExhbmUgTnVtYmVyIDcsIEJsb2NrIEgsIE5lYiBTYXJhaSwgU2FpbmlrIEZhcm0sIE5ldyBEZWxoaSwgRGVsaGkgMTEwMDYyLCBJbmRpYQ
リフレッシュAPIの呼び出し
PlaceIDのリフレッシュAPIは、実際はPlaces Detailsである。
SKU: Places Details
Place Details APIの fields パラメーターにPlaceIDのみ指定して使う。
PlaceIDだけ指定したリクエストは無料になる。
PlaceIDをキーに呼び出し、PlaceIDだけ返ってくる。
SKU: Places Details – ID Refresh
Place Search APIでも fields パラメーターにPlaceIDだけ指定すれば無料で利用できる。
未指定の場合はPlaceIDしか返ってこなかったと思うので、その場合も無料かもしれない。
SKU: Find Place – ID only
実際の運用
実際どのような運用になるか。したことないけど。
PlaceIDの取得
PlaceIDの長さは最大256文字くらい想定？
初回は Place Search か Place Details API を使って PlaceID とその他のデータを取得する。
キャッシュ
閉店の状態は business_status で見るらしい。
その場合にPlaceIDが取得できるのか変更がないのか分からないが、要件によっては保存しておく必要があるかもしれない。
取得したPlaceIDはキャッシュするとして、取得時のリクエストもPlaceIDと一緒に保存しておく。
リフレッシュ
Place Detail API を使って定期的にPlaceIDを更新する。
NOT_FOUND が返ってきた場合は、保持していたリクエストを Place Search API に投げてPlaceIDを取得し直す。
この時、fields パラメーターにPlaceIDだけ指定すれば無料になるが、さすがに他のフィールドを検証しないでPlaceIDだけ更新するのはどうかと思う。
なので、Place SearchでPlaceID以外の情報も有料で取得・検証して問題なければPlaceIDを更新するか、
Place SearchでPlaceIDだけ無料で取得して、Place Detailsで詳細な情報を有料で取得・検証した上でPlaceIDを更新するのかなと思う。