教程
按位置筛选推文
跳转至本页面的以下主题
简介
在处理推文数据时，有两类地理元数据：
- 推文位置 - 如果用户在发推时分享位置，则可用。
- 账号位置 - 基于用户在其公开个人资料中提供的“家庭”位置。这是一个自由格式的字符字段，可能包含可做地理参照的元数据，也可能不包含。
这些将在接下来的两部分中单独说明。
重要提示：
- 地理坐标按 [LONG, LAT] 顺序提供。一个例外是“geo”属性，它已被弃用，其顺序与 [LAT, LONG] 相反。
- 所有 PowerTrack 地理位置运算符都期望坐标顺序为 [LONG, LAT]。
推文位置（“带地理位置标记的”推文）
Twitter 允许用户为单条推文指定位置。PowerTrack 通过其各种运算符，借助推文特定的位置数据提供多种方法来筛选推文（详情请查看我们的 Twitter PowerTrack 运算符文档）。推文特定的位置信息可分为两大类：
- 具有特定经纬度“点”坐标的推文
- 标有 Twitter“地点”的推文（请查看我们的博客文章 Twitter 地点：关于推文的更多信息和我们的 Twitter 地理位置对象文档，了解更多信息）。
带有“点”坐标的推文来自支持 GPS 的设备，它指出相应推文的确切 GPS 位置。这类位置不包含任何关于被提及的 GPS 位置的场景信息（例如相关城市、国家/地区等），除非确切位置可以与 Twitter 地点相关联。
标有 Twitter“地点”的推文包含一个多边形，由 4 个经纬度坐标组成，定义了用户发推的大致区域（“地点”）。此外，在其他字段中，“地点”还将有一个显示名称、类型（如城市、街区），以及与“地点”所在国家/地区相对应的国家/地区代码。
重要提示：转推不能附加“地点”，所以如果你使用 has:geo 等运算符，你将不会匹配任何转推
Twitter 地点 JSON
下面是一个 JSON 示例，它来自标有“Boulder, CO”Twitter 地点的推文。
{
"place": {
"id": "fd70c22040963ac7",
"url": "https:\/\/api.twitter.com\/1.1\/geo\/id\/fd70c22040963ac7.json",
"place_type": "city",
"name": "Boulder",
"full_name": "Boulder, CO",
"country_code": "US",
"country": "United States",
"contained_within": [
],
"bounding_box": {
"type": "Polygon",
"coordinates": [
[
[-105.301758, 39.964069],
[-105.301758, 40.094551],
[-105.178142, 40.094551],
[-105.178142, 39.964069]
]
]
},
"attributes": {}
}
}
确切位置 JSON
在 Twitter 丰富的原生格式中，根级别的“geo”和“coordinates”属性提供了确切位置的十进制坐标。包含该元数据的推文也可以包含上述“Twitter 地点”数据，但不保证同时存在这两者。
请注意，“coordinates”属性的格式为 [经度, 纬度]，而“geo”属性的格式为 [纬度, 经度]。
{
"geo": {
"type": "Point",
"coordinates": [40.0160921, -105.2812196]
},
"coordinates": {
"type": "Point",
"coordinates": [-105.2812196, 40.0160921]
}
}
推文位置运算符
place:
按名称或 ID 筛选特定地点。要发现与特定区域相关的“地点”，请使用 REST API 中的 Twitter reverse_geocode 端点。然后，使用你用 place: 运算符找到的地点 ID 来跟踪包含被提及的特定地点的推文。如果你使用地点名称而不是数字 ID，请确保用引号将任何名称（包含空格或标点符号）引起来。
place_contains:
place_contains: 运算符不针对特定地点进行匹配，而是对照从 Twitter 发送的地点名称进行子串匹配。这可适应 place_contains:”, CO” 之类的概念来匹配包含 “Boulder, CO” 或 “Denver, CO” 等名称的地点。
place_country:
每个 Twitter“地点”都有一个国家/地区代码，表示该地点所在的国家/地区。借助 country_code: 运算符，可在这个 ISO alpha-2 字符代码上进行筛选（请在此处查看国家/地区代码参考）。
has:geo:
借助 has:geo 运算符，可匹配 Twitter 有效负荷内存在的点坐标或地点地理位置信息。请注意，这并不能让你指定特定位置或地理数据类型，它只是要求结果具有某种类型的推文特定位置信息。
point_radius:
借助 point_radius: 运算符可指定一个圆形的地理区域，匹配包含推文特定位置数据且地点在该区域范围内的推文。若要使用它，请定义一个中心点经纬度坐标，然后设置半径（最多 25 英里）。包含地理点坐标且在此区域内的推文都会被匹配。此外，如果为地点定义的地理多边形完全在定义的点坐标半径区域内，那么将匹配包含 Twitter 地点的相应推文。如果地点多边形的任何部分未在定义的点坐标半径区域中，那么将不匹配相应的推文。
用法类似于：point_radius:[lon lat radius]
bounding_box:
借助 bounding_box: 运算符可指定一个四边形的地理区域，并匹配包含推文特定位置数据且地点在该区域范围内的推文。若要使用它，请定义表示四边形对角的经纬度坐标，使四边形每一边的长度不超过 25 英里。包含地理点坐标且在此区域内的推文都会被匹配。此外，如果为地点定义的地理多边形完全在定义的点坐标半径区域内，那么将匹配包含 Twitter 地点的相应推文。如果地点多边形的任何部分未在定义的点坐标半径区域中，那么将不匹配相应的推文。
用法类似于：bounding_box:[west_long south_lat east_long north_lat]
个人资料位置（账号“主页”）
通过位置信息筛选推文的另一种方法是匹配 Twitter 用户个人资料中的位置信息。有几个数据字段属于这一类，但它们都表示用户在账号级别设置的信息类型。用户一般不常更改这些值，它们可能表示用户当前发推的位置，但并非一定如此。
除了 Twitter 提供的个人资料位置外，Gnip 还提供了一项可选的个人资料地理位置改进功能，它可将个人资料位置中的数据形式化，从而能更方便地进行筛选。
个人资料位置元数据
"user": {
"location": "Denver, CO",
"description": "Part-time fiddler, wanderer, yogi, scubadiver #savegamehenge Full time explorer, festvarian, music lover, nerd, @TwitterBoulder",
"created_at": "Wed Aug 05 05:46:48 +0000 2009",
"utc_offset": null,
"time_zone": "null",
"geo_enabled": true,
"lang": "en"
}
启用了个人资料地理位置改进功能后，上述 Twitter 个人资料位置在根级用户对象中会生成以下 user.derived.locations 属性。请注意，user.derived.locations 属性被定义为一个位置数组。虽然目前只提供了一个位置，但个人资料地理位置改进功能未来可能能够解析用户个人资料位置中提到的多个位置。请查看此处，了解
有关个人资料地理位置改进功能的更多信息。
个人资料地理位置元数据
注意：所有个人资料地理位置坐标均按照 [经度, 纬度] 的顺序提供。
"user": {
"location": "Denver, CO",
"description": "Part-time fiddler, wanderer, yogi, scubadiver #savegamehenge Full time explorer, festvarian, music lover, nerd, @TwitterBoulder",
"derived": {
"locations": [{
"country": "United States",
"country_code": "US",
"locality": "Denver",
"region": "Colorado",
"sub_region": "Denver County",
"full_name": "Denver, Colorado, United States",
"geo": {
"coordinates": [-104.9847, 39.73915],
"type": "point"
}
}]
}
"created_at": "Wed Aug 05 05:46:48 +0000 2009",
"utc_offset": null,
"time_zone": "null",
"geo_enabled": true,
"lang": "en"
}
个人资料位置运算符
其他地理位置运算符
如果启用了个人资料地理位置改进功能，则可使用以下运算符来创建规则：
has:profile_geo
无论值如何，该筛选条件都会匹配特定推文中存在的个人资料地理位置改进数据。这将仅匹配用户“主页”设置在地理位置上成功提及至少国家/地区级别的推文。例如，如果用户账号主页设置为“互联网”，则该用户的推文将不匹配该运算符，但主页设置为“美国”则匹配。
profile_point_radius: / profile_bounding_box:
匹配存在 Gnip 个人资料地理位置改进数据且地点在定义的点坐标半径或边界框区域内的推文。注意：这将仅匹配 Gnip 能够提供 Twitter 用户提供的个人资料位置官方地理位置信息的推文，这与这里的改进功能描述一致。
用法类似于：
profile_point_radius:[lon lat radius]
profile_bounding_box:[west_long south_lat east_long north_lat]
profile_country:
匹配存在 Gnip 个人资料地理位置改进数据且包含定义的国家/地区代码的推文。注意：这将仅匹配 Gnip 能够提供 Twitter 用户提供的个人资料位置官方地理位置信息的推文，这与这里的改进功能描述一致。
profile_region:
匹配存在 Gnip 个人资料地理位置改进数据并包含指定“区域”的推文。 请注意，profile_region: 将执行精确的字符串匹配。这将仅匹配 Gnip 能够提供 Twitter 用户提供的个人资料位置官方地理位置信息的推文，这与这里的改进功能描述一致。
profile_locality:
匹配存在 Gnip 个人资料地理改进数据并包含指定“所在地”的推文。 请注意，profile_locality: 将执行精确的字符串匹配。这将仅匹配 Gnip 能够提供 Twitter 用户提供的个人资料位置官方地理位置信息的推文，这与这里的改进功能描述一致。
标准个人资料位置运算符
以下运算符可用于筛选用户 Twitter 个人资料位置中提到的位置，而且无论是否启用个人资料地理位置改进功能都可使用：
bio_location:
bio_location: 运算符对用户的账号级位置字段进行标记化匹配。请注意，该字段是用户生成的，不一定反映实际位置，并且在不同的推文中保持一致。
其他地理位置运算符
以下附加的运算符会筛选虽然不是明确的位置字段，但有时包含基于账号的位置信息的字段
bio_contains:
对用户账号级简介进行子串匹配，该简介由用户生成的文本组成，可能不包括位置信息。可用于实时 PowerTrack 和 Historical PowerTrack。
bio_lang:
根据与用户相关的账号级语言匹配推文。该语言在账号级设置，将由 ISO 639-1 语言代码表示。请注意，Twitter 并不支持 ISO 639-1 列表中的所有语言，而且该语言可能实际上并不反映用户的真实语言，因为有一些默认值，且用户可以更改该值。
用法示例
在许多情况下，你可能希望尽可能多地获取与位置相关的数据，不管这些信息是作为推文特定信息存在，还是作为用户账号元数据中包含的信息存在。以下是如何在规则中结合使用各种运算符来捕获更多数据类型的示例。在这些示例中，规则将查找包含各种位置数据类型的话题标签“#FlagstaffFire”的提及内容。
- 标有地理位置，且地点在边界框内或与提及“Boulder”的 Twitter 地点关联的推文
#FlagstaffFire (bounding_box:[-105.301758 39.964069 -105.178505 40.09455] OR place:Boulder) - 个人资料位置采用标准个人资料位置运算符提及 Boulder, CO 但未提及 Boulder, NV 的用户的推文：
#FlagstaffFire bio_location:boulder -(bio_location:nevada OR bio_location:", NV") - 个人资料位置采用个人资料地理位置运算符提及 Boulder, CO 但未提及 Boulder, NV 的用户的推文：
#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 ))
后续步骤
准备好构建你的解决方案了吗？