谷歌地圖地理編碼查詢限制v2和v3之間的區別

當我在v2中執行客戶端地理編碼請求時，我能夠以200ms的間隔連續做很多請求。但是在v3中，我必須將間隔增加到2秒以避免OVER_QUERY_LIMIT錯誤。這意味着在Maps v3中，我的地理編碼將會慢很多。谷歌地圖地理編碼查詢限制v2和v3之間的區別

Maps API v2和v3之間的這種區別對我來說似乎很奇怪。有沒有其他人也遇到過這個問題，還是僅僅是我？有什麼方法可以使用v2 geocoder而頁面的其餘部分使用v3？

PS。我主要關注反向地理編碼（latlng-> address），它比正常的地理編碼更慢。

來源

2011-04-28 Rene Saarsoo

我在應用程序中所做的事情儘可能多地盡我所能。每當我打開OVER_QUERY_LIMIT時，我都會讓線程休眠5秒鐘，然後重試。這很好。我做了一些嘗試，找出它可以處理多少，並且似乎在短時間內有10個查詢是極限。然後你必須等一下。

我不認爲有可能使用這兩個API的，因爲你將不得不包括這兩個.js文件，並且必然會有一些東西具有相同的名稱，並會導致行爲，你不能真的預測。

但我可以說的一件事是，如果你必須在客戶端做所有事情，你似乎做錯了什麼。您是不是將這些位置存儲在數據庫或其他東西中的選項，然後只有在新的東西出現時才進行查找？

來源

2011-04-28 16:41:12

是的，這是我目前使用的策略：在OVER_QUERY_LIMIT後再次嘗試。是的，我確定服務器端緩存會有所幫助，但事實是，在v2中不需要這種緩存，地理編碼速度提高了10倍。 PS：我應該注意到，我最關心的是反向地理編碼，它似乎比普通地址 - > latlng地理編碼慢。 – 2011-04-29 07:25:52

在第2版中，您還必須定義一個密鑰，向Google展示所有請求都來自您的網站，並且每個網站在一天內可能會對其請求有限制。在新版本中沒有密鑰，我認爲這是他們不允許再發出更多請求的原因之一，因爲請求將從客戶端IP發出，並且您可以在請求期間加載更多請求來自不同知識產權的一天。但這只是我的推測:) – 2011-04-29 11:56:20

我在v2中的經驗是，客戶端地理編碼限制是按客戶端計算的，而不是按API密鑰計算 - 這是我們在客戶端執行此操作的主要原因。 – 2011-04-29 12:37:09

谷歌地圖地理編碼查詢限制v2和v3之間的區別

回答

相關問題