我試圖反向地理緯度/長到使用谷歌地圖API V3最接近的路口。此外，現在，這並不一定要非常準確 - 因爲我只是試圖匿名地址而不是提供方向。
我已經看到了地址解析結果數據中包含「交集」的Address Component Type，但是這似乎並沒有一致的回報results--可言，更往往是不爲空。
我也做了一些找上左右爲最佳的方式來構建這種禁止直接得到它從谷歌，和我見過的最接近的是：How can I find the nearest intersection via the Google Maps API?，它並沒有真正解決我的問題。鑑於此，我已經提出了自己的解決方案，並且希望完全能夠提出一些意見，優化，建設性批評或其他選擇。
我的初步解決方案：
與API玩弄後，我決定給以下算法一槍（僅適用於上下文，這是用C＃編寫一個控制檯應用程序中）：
我接收一個地址並將其解析爲緯度/經度。
我再增加或減少一定量的緯度或長期從 一個街區（被調整給您 緯度的距離）的順序coordinate--與點之間的行走路線。我這樣做是爲了達到所有四個方向 - 所以第一個修改是保持緯度相同，但是減去的一些經度。那麼接下來的修改是將保持緯度和添加一些經度等
獲取路線後，我分析的結果和檢查開始 和結束地址。如果他們不同，我把街道名稱 拿出來，把它們當作一個「十字路口」（儘管有時候這個路段會在平行的街道上產生 - 也只是試圖獲得一個球場）。
如果我找不到兩條不同的街道，我會擴大最終目的地的距離並重復此過程。
到目前爲止，這方面的工作做得不夠好，但很明顯這是一個昂貴的過程無論是在時間上，並且在使用我的分配查詢限制。另外，我檢查了API的服務條款，只要我包含他們的免責聲明並在Google Map上顯示結果，我認爲我沒問題。
我對社會問題是：
我怎樣才能提高算法的效率？具體來說，在 我調用API的次數（執行代碼不是 問題）
是否有另一種方法可以完全使用Google Maps API來執行此操作？ 在SO問題referred to above中，解決方案是在建築物編號上循環 。我不確定這到底意味着什麼 - 所以任何澄清都會很好。
如上所述，我不認爲這是違反服務條款 - 但我錯了嗎？
是否有另一種基於網絡的API可以更好地滿足我的需求？ 也許Bing或其他提供者？
非常感謝您的幫助。
UPDATE： 我遇到了我的查詢限制的一天，所以我今天不能來測試對谷歌的任何建議，但我也仍然是開放的使用不同的API。謝謝。