ツイートデータを扱う際は次の2つのクラスの地理メタデータが利用できます。

• ツイートの位置情報 - ツイート時にユーザーが位置情報を共有した場合に利用できます。
• アカウントの位置情報 - 公開プロフィールでユーザーが指定した「ホーム」の位置情報に基づいています。自由入力形式の文字フィールドで、ジオリファレンスできるメタデータが含まれている場合と含まれていない場合があります。

それぞれについて、次の2つのセクションで個別に説明します。

重要:

• 地理座標は [LONG, LAT] の順番で提供されます。例外が1つあり、非推奨の「geo」属性では逆の [LAT, LONG] の順番となります。
• すべてのPowerTrack地理演算子で座標を [LONG, LAT] の順番にする必要があります。
  

Twitterではユーザーがツイートごとに位置情報を指定できます。PowerTrackには、さまざまな演算子を使用してツイート固有の位置情報データでツイートをフィルタリングする方法が複数用意されています（詳細についてはTwitter PowerTrack演算子のドキュメントを参照してください）。ツイート固有の位置情報は次の2つの一般カテゴリに分類されます。

• 特定の緯度/経度「Point」座標を持つツイート
• Twitterの「Place」を含むツイート（詳細については、ブログ投稿「Twitter Place:ツイートにコンテキストを追加する」とTwitterのジオオブジェクトに関するドキュメントを参照してください）。

Point座標を含むツイートは、GPS対応デバイスから投稿され、対象ツイートの正確なGPS位置情報を表します。正確な位置情報をTwitter Placeと関連付けられる場合を除き、このタイプの位置情報には参照されるGPS位置情報（関連する都市や国など）に関するコンテキスト情報は含まれません。

Twitterの「Place」があるツイートにはポリゴンが含まれます。ポリゴンは、ユーザーがツイートを投稿した一般エリア（「Place」）を定義する4つの経度-緯度座標で構成されます。さらに、Placeには表示名、タイプ（都市や地域など）、Placeが位置する国に対応する国コードなどのフィールドがあります。

重要:リツイートにはPlaceを配置できないため、has:geoなどの演算子を使用する場合リツイートには一致しません。

以下は、「Boulder, CO」というTwitter Placeでジオタグ付けされたツイートのJSONサンプルです。

Twitterが情報を付加したネイティブ形式の場合、ルートレベルの「geo」属性と「coordinates」属性によって正確な位置の十進角の座標が提供されます。このメタデータを含むツイートには前述の「Twitter Place」データを含めることができますが、両方が含まれることが保証されるわけではありません。

「coordinates」属性の形式が [LONGITUDE, latitude] になるのに対して、「geo」属性の形式は [latitude, LONGITUDE] になるので注意が必要です。

place:
名前かIDで特定のPlaceをフィルタリングします。特定のエリアに関連付けられている「Places」を見つけるには、REST APIでTwitterのreverse_geocodeエンドポイントを使用します。次にplace:演算子で見つけたPlace IDを使用して、参照される特定のPlaceを含むツイートを追跡します。数値IDの代わりにPlace名を使用する場合、スペースまたは句読点を含む名前は引用符で囲むようにしてください。

place_contains:
place_contains:演算子では特定のPlaceを照合するのではなく、Twitterから送信されたPlace名に対して部分文字列の照合を実行します。「Boulder, CO」や「Denver, CO」などの名前を含むPlaceに一致するようにplace_contains:”, CO”といったコンセプトにも対応できます。

place_country:
各Twitter「Place」にはPlaceの所在国を示す国コードが含まれます。country_code:演算子を使用すると、このISO alpha-2文字コードに対してフィルタリングを実行できます（国コードについてはこちらを参照してください）。

has:geo:
has:geo演算子は、Twitterペイロード内にPointまたはPlaceの地理情報が存在するかどうかを照合します。特定の位置やジオデータのタイプを指定することはできません。この演算子の要件は、結果に何らかのツイート固有位置情報が含まれているということです。

point_radius:
point_radius:演算子を使用すると、円形の地理領域を指定して、その領域内でツイート固有の位置情報データを含むツイートを照合できます。この演算子を使用するには、中心にする経度-緯度座標を定義してから半径（最大25マイル）を設定します。この領域内にあるジオPointを含むすべてのツイートに一致します。また、Twitter Placeを含むツイートは、定義したポイント-半径領域内に完全に収まるPlaceに定義されたジオポリゴンの位置に一致します。定義したポイント-半径領域外にポリゴンがあるPlaceは一致とみなされません。

この演算子は次のように使用します: point_radius:[lon lat radius]

bounding_box:
bounding_box:演算子を使用すると、4辺で囲まれた地理領域を指定して、その領域内でツイート固有の位置情報データを含むツイートを照合できます。この演算子を使用するには、ボックスの各辺の長さが25マイル以内になるように、ボックスの対角を表す経度-緯度座標を定義します。この領域内にあるジオPointを含むすべてのツイートに一致します。また、Twitter Placeを含むツイートは、定義したポイント-半径領域内に完全に収まるPlaceに定義されたジオポリゴンの位置に一致します。定義したポイント-半径領域外にポリゴンがあるPlaceは一致とみなされません。

この演算子は次のように使用します: bounding_box:[west_long south_lat east_long north_lat]

Twitterユーザーのプロフィール内の位置情報を照合して、位置情報でツイートをフィルタリングすることもできます。このカテゴリには、複数のデータフィールドがありますが、いずれもアカウントレベルでユーザーが設定した情報の種類を表しています。通常、これらの値はユーザーによって頻繁に変更されることはなく、必ずしもユーザーが現在ツイートしている場所を表すものではありません。

Twitterが提供するプロフィールの位置情報に加え、Gnipにはプロフィールの位置情報にあるデータの形式を整え、フィルタリングしやすくするためのオプションのプロフィールのジオエンリッチメントが用意されています。

プロフィール位置情報メタデータ

プロフィールのジオエンリッチメントを有効にすると、上述のTwitterプロフィール位置情報がルートレベルユーザーオブジェクトに続くuser.derived.locations属性になります。user.derived.locations属性は位置の配列として定義されます。現在提供されている位置情報は1つだけですが、プロフィールのジオエンリッチメントでは将来的に、ユーザーのプロフィール位置情報で触れられている複数の位置情報に対応できるようになる可能性があります。プロフィール用のジオエンリッチメントの詳細についてはこちらを
参照してください。

プロフィールのgeoメタデータ
注: すべてのプロフィールの地理座標は [Longitude, Latitude] の順番で提供されます。

プロフィールの地理演算子
プロフィールのジオエンリッチメントを有効にしている場合は、ルールの構築に次の演算子を使用できます。

has:profile_geo
このフィルターは、値に関係なく、特定のツイートにプロフィールのジオエンリッチメントデータがあるかどうかを照合します。ユーザーの「ホーム」設定が、少なくとも国レベルでジオリファレンスされているツイートのみを照合します。たとえば、アカウントのホームを「インターネット」に設定しているユーザーのツイートはこの演算子では一致とみなされませんが、「USA」をホームにしている場合は一致とみなされます。

profile_point_radius: / profile_bounding_box:
Gnipのプロフィールのジオエンリッチメントデータを利用でき、定義したポイント-半径領域か境界ボックス領域に収まるツイートを照合します。注: Twitterユーザーが提供するプロフィール位置情報の正式な地理的情報をGnipが提供でき、こちらのエンリッチメントの説明と一貫性があるツイートのみを照合します。

この演算子は次のように使用します:

profile_point_radius:[lon lat radius]

profile_bounding_box:[west_long south_lat east_long north_lat]

profile_country:
Gnipのプロフィールのジオエンリッチメントデータを利用でき、定義した国コードを含むツイートを照合します。注: Twitterユーザーが提供するプロフィール位置情報の正式な地理的情報をGnipが提供でき、こちらのエンリッチメントの説明と一貫性があるツイートのみを照合します。

profile_region:
Gnipのプロフィールのジオエンリッチメントデータを利用でき、指定した「region」を含むツイートを照合します。 profile_region:は文字列の完全一致検索を実行します。Twitterユーザーが提供するプロフィール位置情報の正式な地理的情報をGnipが提供でき、こちらのエンリッチメントの説明と一貫性があるツイートのみを照合します。

profile_locality:
Gnipのプロフィールのジオエンリッチメントデータを利用でき、指定した「locality」を含むツイートを照合します。 profile_locality:は文字列の完全一致検索を実行します。Twitterユーザーが提供するプロフィール位置情報の正式な地理的情報をGnipが提供でき、こちらのエンリッチメントの説明と一貫性があるツイートのみを照合します。

以下の演算子は、ユーザーのTwitterプロフィール位置情報に含まれている位置情報をフィルタリングするのに使用でき、プロフィールのジオエンリッチメントを有効にする必要はありません。

bio_location:
bio_location:演算子は、ユーザーのアカウントレベルの位置情報フィールドに対してトークン化された照合を実行します。このフィールドはユーザーによって生成され、必ずしも実際の位置を反映したものではなく、通常はツイートごとに変更されません。

以下の追加の演算子は、位置情報フィールドに限らず、アカウントベースの位置情報を含む可能性があるフィールドをフィルタリングします。

bio_contains:
ユーザー生成テキストで構成され、位置情報を含むかどうかわからない、ユーザーのアカウントレベルの自己紹介に対して部分文字列の照合を実行します。リアルタイムと履歴のPowerTrackで利用できます。

bio_lang:
ユーザーに関連付けられたアカウントレベルの言語に基づいてツイートを照合します。この言語はアカウントレベルで設定され、ISO 639-1言語コードで表されます。TwitterではISO 639-1リストにあるすべての言語に対応しているわけではありません。また、言語にはデフォルト値があり、ユーザーが値を変更できるため、必ずしもユーザーの実際の言語を反映しているとは限りません。

多くのケースで、情報がツイート固有のものであるか、ユーザーのアカウントメタデータに含まれているかに関係なく、位置に関連するデータをできるだけ多く取得したい場合があります。以下は、ルールでさまざまな演算子を組み合わせて、より多くの種類のデータを取得する方法を示した例です。これらの例では、ルールによって、ハッシュタグ「#FlagstaffFire」を持ち、さまざまな種類の位置情報を含むものを検索します。

• 境界ボックス内にあるか、または「Boulder」を含むTwitter Placeに関連付けられた、ジオタグ付きツイート:
  #FlagstaffFire (bounding_box:[-105.301758 39.964069 -105.178505 40.09455] OR place:Boulder)
• 標準的なプロフィールの位置情報演算子を使用した、「Boulder, NV」ではなく「Boulder, CO」を含むプロフィールの位置情報があるユーザーのツイート:
  #FlagstaffFire bio_location:boulder -(bio_location:nevada OR bio_location:", NV")
• プロフィールの地理演算子を使用した、「Boulder, NV」ではなく「Boulder, CO」を含むプロフィールの位置情報があるユーザーのツイート:
  #FlagstaffFire profile_locality:boulder profile_region:colorado
• プロフィールの地理演算子を使用した、「Boulder, CO」エリアから投稿されたことを示す情報がいずれかのフィールドに含まれるツイート:
  #FlagstaffFire (point_radius:[-105.292778 40.019444 25mi] OR place:"Boulder, CO" OR (profile_locality:boulder profile_region:colorado ))