如何在 Google Map Geocoder V3 中获得等效的精度

Question

我想从谷歌获取地理编码，我曾经使用 API 的 V2 来完成。 谷歌在 json 中发送了一个相当不错的信息，准确性，参考这里：http://code.google.com/intl/fr-FR/apis/maps/documentation/javascript/v2/reference.html#GGeoAddressAccuracy

在 V3 中，Google 似乎并未向我发送完全相同的信息。有一个数组“adresse_component”，如果精度更好，它看起来更大，但不完全是。 例如，我对街道号有一个请求精度，数组的大小为 8。 另一个查询是路线的准确性，因此准确性较低，但数组的大小仍然为 8，因为有一行“子局部性”，在第一种情况下没有出现。

好的，对于结果，Google 会发送一个数据“类型”，它具有“最佳”准确性。这种类型在这里：http://code.google.com/intl/fr-FR/apis/maps/documentation/geocoding/#Types 但是，没有真正的顺序，如果我不希望结果比 postal_code 更好，我不知道该怎么做。

那么，如果没有一些愚蠢而可怕的代码，我如何才能获得与 V2 相当的精度？

Answer 1

嗯，有location type，还不错：

location_type 存储有关指定位置的附加数据。这 目前支持以下值：

“ROOFTOP”表示返回的结果是一个精确的地理编码，我们的位置信息精确到街道地址的精确度。

“RANGE_INTERPOLATED”表示返回的结果反映了一个 近似值（通常在道路上）在两个精确之间插值 点（例如交叉点）。插值结果一般为 当街道地址的屋顶地理编码不可用时返回。

"GEOMETRIC_CENTER" 表示返回的结果是几何 结果的中心，例如折线（例如街道）或 多边形（区域）。”

“APPROXIMATE”表示返回结果为 近似值。

我测试 location_type 是否与近似值不同，它给出了一些好的结果。

Answer 2

随着谷歌在今年晚些时候弃用他们的 Geocoding v2 API，将会有很多人将他们的地理编码逻辑迁移到 v3，这个问题将会突然出现：如何将 'location_type' 字符串映射到等效的 '准确率？

这是一个不错的映射：

"ROOFTOP" -> 9
[Everything else] -> 4 to 8 (aka the text string might as well read "GARBAGE")

如果指定了 ROOFTOP 以外的其他内容，请使用“northeast”和“southwest”的区域来确定它是否对您来说足够准确。

现在，如果您没有得到“准确”的信息，会发生什么？对同一地址运行 Google 地方信息文本搜索查询。 Google Places 也进行地理编码，启用 Billing 后，您每天可以获得 10,000 个 Places 文本搜索查询（无速率限制），Google 声称他们不会从卡上收费（他们应该只是用它来验证帐户）。使用 Billing，您可以获得 100,000 个查询，但 Places 文本搜索查询的“成本”是常规 Places 查询量的 10 倍，因此上述 10,000 个限制。不过，地点可能很挑剔，您应该只考虑只有一个结果的响应。

有时 Places 查询不会返回邮政编码，尤其是在未发送邮政编码的情况下。如果您需要邮政编码，请获取 Places 查询的 lat/lng 结果并将其反馈给地理编码器，地理编码器通常会输出带有邮政编码的地址（并且经常与 ROOFTOP 匹配）。

需要注意的是，官方的 Geocoding API 礼貌限制是每天 2,500 个请求，每个 IP 地址的速率限制为每秒 1 个。因此，遵循上述公式可能会使您可用的地理编码数量减少甚至减半。

如果您需要超过 Google 地理编码限制（谁不需要？），请使用 OpenStreetMap 数据库之类的东西发明您自己的迷你地理编码服务。克隆您需要的 OpenStreetMap 部分并编写自己的地理编码器（或使用库）。然后，您可以根据自己的喜好进行地理编码，没有数量限制或速率限制。如果您仍在使用 Google 地图，您可以使用 Google 的地理编码器作为备用，以防 OSM 地理编码器在所有情况下都不够准确。

或者，如果您相信您的用户不会提交虚假数据（真的吗？）并且必须使用 Google 地理编码服务，您还可以通过为您提供浏览器地理编码信息来滥用用户的网络浏览器，然后将结果提供给你的服务器。您可能会烧毁用户的每日限额，并且冒着有人推送虚假数据的风险，但如果您遇到所有这些麻烦，您真的在乎吗？

无论如何，以上提示应该足以让大多数用户临时使用来设置有效的 v3 API。我自己遇到了这个问题，所以我想我会与社区分享一个不错的解决方案。我仍然认为 v2 是更好的 API - 整数准确度评级而不是丑陋的文本字符串总是胜出。

Answer 3

Paula 的回答很好，但您还需要考虑 John 的评论，即 ROOFTOP 可以返回垃圾。

我使用地理代码查询后健全性检查器来摆脱那些 location_type 为“ROOFTOP”但地址与您发送给谷歌的地址无关的情况 - 这个健全性检查器将新地址与旧地址进行比较地址并考虑发生了什么变化以及变化了多少。谷歌地理编码器有时擅长修正拼写错误，但它也可以做出一些无意义的决定——例如选择不同的城市、不同的州或不同的国家。您需要确定结果是修复了拼写错误还是地理编码逻辑误入歧途。

所以，不要只假设 ROOFTOP == 9。如果新地址与您发送的原始地址相差甚远，它也可能是垃圾。

对于诸如公寓或具有多个单元的建筑，当结果类型为“子前提”时，location_type = 'RANGE_INTERPOLATED'可能也是准确的。

请记住，地理编码与地址验证不同。它们有一些重叠，但即使您的输入是垃圾，谷歌地理编码逻辑也会尽力为您提供答案。