我有一个应用程序，它使用一定的距离半径在用户的当前位置周围生成一些令牌。然后，用户将不得不跑到其中一些位置。问题是可以在湖泊、森林、海洋或其他一些物理上无法到达的位置创建一些令牌。作为快速修复，我只生成额外的令牌并增加确定用户是否到达某个位置的接近距离。我现在想改进这一点，以便每个令牌都位于可到达的位置。
我能想到的唯一解决方案是使用 Google Directions API 来确定从用户到令牌的路径，并使用折线中的最后一个坐标作为令牌的新可达位置。我的问题是我可能必须同时向方向服务发布多达 30 个请求，我担心我可能会达到查询速率限制。我还没有找到任何关于查询速率限制的明确信息。
所以我的问题是，是否有人知道更好的解决方案或可以就方向查询速率限制提供任何输入？在每个请求之间等待 1 秒并强制用户等待最多 30 秒并不是一个合理的解决方案。谢谢。
更新 使用我在问题中描述的解决方案确实会产生 OVER_QUERY_LIMIT，即使我在每个请求之间等待 1 秒。除此之外，逻辑是合理的，并且通过请求获得的令牌出现在步行可达的位置。
您可以使用 Location.distanceBetween() 计算两个纬度/经度之间的距离。这是一个静态便利 API 调用。计算次数没有限制。
使用 Google Directions API 的查询限制为每天 2,500 个路线请求。单个路线请求在请求中最多可包含 8 个中间航路点。
Google Maps Premier 客户每天最多可以查询 100,000 个路线请求，每个请求最多允许 23 个航点。
您可能想了解一下 Maps 的首要客户，以免过快达到限制。如果您的应用程序变得流行，我敢打赌您可以获得更高的限制。
一种方法是看看你是否能看到海拔，看看它是否是悬崖。然而，仅仅看它是否是一个湖似乎很难。可能是某种 gps 查找服务，除了谷歌地图。
如果您只想知道位置之间的距离，只需使用Location.distanceTo()或静态distanceBetween() 获取信息是否是道路是另一个问题。
大约 8 小时后，我终于得到了一些工作。因此，使用每个请求最多可以有 8 个航点这一事实，我可以在一个请求中从技术上询问到 9 个位置的方向。这就是我现在正在做的事情：
一次生成 9 个随机位置。将位置传递给我的 DirectionsComputer，它将通过所有 9 个坐标的折线路径作为坐标列表返回。然后我从路径中选择 9 个位置并将它们设置为我的令牌的位置。现在我所有的token都是半随机生成的，总是出现在一条路上，我只需要连续做4次请求就可以生成36个token。
在某些情况下，几个令牌捆绑在一起。例如，最初位于海洋中的坐标被移动到同一个海滩。但在大多数情况下，我所有的测试都显示令牌分散开来，我可以调整其余部分。