如何获得与 Google Map Geocoder V3 相当的精度
我想从google获取地理编码，我以前是用API的V2来实现的。 Google 在 json 中发送了一个非常好的信息，准确度，参考这里：http://code.google.com/intl/fr-FR/apis/maps/documentation/javascript/v2/reference.html#GGeoAddressAccuracy
在 V3 中，Google 不会似乎没有向我发送完全相同的信息。有一个数组“adresse_component”，如果精度更好，它看起来更大，但不完全一样。 例如，我请求精确到街道号码，数组大小为 8。 另一个查询是路线的准确性，因此准确性较低，但数组的大小仍然是 8，因为有一行“sublocality”，这在第一种情况下没有出现。
好吧，对于结果，谷歌发送了一个具有“最佳”准确性的数据“类型”。此类型位于：http://code。 google.com/intl/fr-FR/apis/maps/documentation/geocoding/#Types 但是，没有真正的顺序，如果我不希望结果比 postal_code 更好，我不知道如何做到这一点。
那么，我怎样才能获得相当于 V2 精度的结果，而不需要一些愚蠢而可怕的代码呢？
I want to get geocode from google, and I used to do it with the V2 of the API.
Google send in the json a pretty good information, the accuracy, reference here : http://code.google.com/intl/fr-FR/apis/maps/documentation/javascript/v2/reference.html#GGeoAddressAccuracy
In V3, Google doesn't seem to send me exactly the same information. There is the array "adresse_component", which seem bigger if the accuracy is better, but not exactly.
For example, I have a request accuracy to the street number, the array is of size 8.
Another query is accuracy to the route, so less accuracy, but the array is still of size 8, as there is a row 'sublocality', which not appear in the first case.
Ok, for a result, Google send a data 'types', which have the 'best' accuracy. This types are here : http://code.google.com/intl/fr-FR/apis/maps/documentation/geocoding/#Types
But, there is no real order, and if I wan't the result better than postal_code, I have no clue to how to do that.
So, how can I get this equivalent of the V2 accuracy, whithout some dumb and horrible code ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
嗯，还有位置类型，这还不错：
我测试了 location_type 是否与近似值不同，它给出了一些不错的结果。
Well, there is the location type, which is not so bad :
I test if the location_type is different of approximate, and it gives some good results.
随着谷歌今年晚些时候弃用他们的地理编码 v2 API，将会有很多人将他们的地理编码逻辑迁移到 v3，并且这个问题将会出现：如何将“location_type”字符串映射到等效的“准确性”？
这是一个不错的映射：
如果指定了 ROOFTOP 以外的其他内容，请使用“东北”和“西南”的区域来确定它对您来说是否足够准确。
现在，如果您没有得到“准确”的信息，会发生什么？对同一地址运行 Google Places 文本搜索查询。 Google Places 也进行地理编码，并且在启用计费的情况下，您每天可以获得 10,000 个 Places 文本搜索查询（无速率限制），并且 Google 声称他们不会向该卡收取费用（据说他们只是用它来验证帐户）。通过 Billing，您可以获得 100,000 个查询，但地点文本搜索查询的“成本”是常规地点查询量的 10 倍，因此存在上述 10,000 个限制。不过，地点可能很挑剔，您应该只考虑只有一个结果的响应。
有时，地点查询不会返回邮政编码 - 特别是在未发送邮政编码的情况下。如果您需要邮政编码，请获取地点查询的纬度/经度结果并将其反馈给地理编码器，地理编码器通常会输出带有邮政编码的地址（并且经常是 ROOFTOP 匹配）。
应该注意的是，官方地理编码 API 礼节限制为每天 2,500 个请求，速率限制为每个 IP 地址每秒 1 个。因此，遵循上述公式可能会减少甚至可能使您可用的地理编码数量减半。
如果您需要超过 Google 地理编码限制（谁不需要？），请使用 OpenStreetMap 数据库之类的工具发明您自己的迷你地理编码服务。克隆您需要的 OpenStreetMap 部分并编写您自己的地理编码器（或使用库）。然后，您可以根据自己的喜好进行地理编码，没有数量限制或速率限制。如果您仍然使用 Google 地图，如果 OSM 地理编码器对于所有情况都不够准确，则可以使用 Google 地理编码器作为后备。
或者，如果您相信您的用户不会提交虚假数据（真的吗？）并且必须使用 Google 地理编码服务，您也可以通过为您提供浏览器地理编码信息来滥用用户的网络浏览器，然后将结果提供给您的服务器。您可能会耗尽用户的每日限额，并且冒着有人推送虚假数据的风险，但如果您遇到所有这些麻烦，您真的在乎吗？
无论如何，上述提示应该足以供大多数用户临时使用，以设置有效的 v3 API。我自己也遇到了这个问题，所以我想与社区分享一个还算不错的解决方案。我仍然认为 v2 是更好的 API - 整数准确度评级而不是丑陋的文本字符串总是胜出。
With Google deprecating their Geocoding v2 API later this year, there's going to be a ton of people migrating their geocoding logic to v3 and this very question is going to crop up: How to map the 'location_type' string to an equivalent 'accuracy'?
Here's a decent mapping:
If something other than ROOFTOP is specified, use the area of 'northeast' and 'southwest' to decide if it is accurate enough for you.
Now what should happen if you don't get something "accurate"? Run a Google Places text search query for the same address. Google Places does geocoding as well and, with Billing enabled, you can get 10,000 Places text search queries per day (no rate limit) and Google claims they won't charge the card (they supposedly just use it for verifying the account). With Billing, you get 100,000 queries, but Places text search queries have a "cost" of 10 times the amount of a regular Places query, hence the aforementioned 10,000 limit. Places can be finicky though and you should only consider responses with one result.
Sometimes Places queries will not return a zipcode - especially if one isn't sent. If you need the zipcode, take the lat/lng results of the Places query and feed it back into the geocoder, which will usually spit out an address with a zipcode (and very frequently a ROOFTOP match).
It should be noted that the official Geocoding API courtesy limit is 2,500 requests per day with a rate limit of one per second per IP address. Therefore, following the above formula will likely decimate and may even halve the number of geocodings available to you.
If you need more than the Google Geocoding limit (who doesn't?), invent your own mini geocoding service with something like the OpenStreetMap database. Clone the parts of OpenStreetMap that you need and write your own geocoder (or use a library). Then you can geocode to your heart's content with no quantity limit or rate limit. If you still use Google Maps, you can use Google's geocoder as a fallback should the OSM geocoder not be accurate enough for all cases.
Alternatively, if you trust your users to not submit bogus data (really?) and have to use the Google geocoding service, you could also abuse a user's web browser by having the browser geocode information for you and then feed the results to your server. You might burn through the user's daily limit and you risk someone pushing bogus data, but if you are going to all that trouble, do you actually care?
At any rate, the tips above should suffice for interim usage for most users to get a working v3 API set up. Ran into this issue myself, so figured I'd share with the community a halfway decent solution. I still think v2 was the better API - integer accuracy ratings instead of ugly text strings always wins out.
Paula 的回答很好，但您确实还需要考虑 John 的评论，即 ROOFTOP 可能返回垃圾。
我使用地理编码查询后健全性检查器来消除那些 location_type 为“ROOFTOP”但该地址与您发送到谷歌的地址无关的情况 - 该健全性检查器将新地址与旧地址进行比较并考虑发生了什么变化以及变化了多少。谷歌地理编码器有时擅长修复拼写错误，但它也可能做出一些无意义的决定 - 例如选择不同的城市，不同的州或不同的国家。您需要确定结果是否修复了拼写错误，或者地理编码逻辑是否误入歧途。
因此，不要仅仅假设 ROOFTOP == 9。如果新地址与您发送的原始地址相差甚远，它也可能是垃圾。
对于公寓或具有多个单元的建筑物之类的情况，当结果类型为“子前提”时，location_type = 'RANGE_INTERPOLATED'可能也是准确的。
请记住，地理编码与地址验证不同。它们有一些重叠，但谷歌地理编码逻辑太努力地试图给你一个答案，即使你的输入是垃圾。
Paula's answer is good but you do need to also consider John's comment that ROOFTOP can return garbage.
I use a post-geocode-query sanity checker to get rid of those cases where location_type is 'ROOFTOP' but the address has nothing to do with the address you sent to google - this sanity checker compares the new address with the old address and considers what changed and by how much. The google geocoder is good at fixing typos, sometimes, but it can also make some non-sensical decisions - for instance choose a different city, a different state, or a different country. You need to decide if the result is a fix in a typo or if the geocode logic went astray.
So, don't just assume ROOFTOP == 9. It can also be garbage if the new address is way off from the original that you sent.
For things like Apartments or building with multiple units, the location_type = 'RANGE_INTERPOLATED' may also be accurate when the result type is 'subpremise'.
Remember, geocoding is not the same thing as address validation. They have some overlap but google geocode logic tries too hard to get you an answer, even when your input is garbage.