创建位于物理上可到达的位置的随机纬度/经度坐标
我有一个应用程序，它使用特定的距离半径在用户当前位置周围生成一定数量的令牌。然后，用户将不得不跑到其中一些位置。问题是一些代币可以在湖泊、森林、海洋或其他物理上无法到达的位置创建。作为快速修复，我只是生成额外的令牌并增加确定用户是否到达某个位置的接近距离。我现在想改进这一点，以便每个令牌都位于可到达的位置。
我能想到的唯一解决方案是使用 Google Directions API 来确定从用户到令牌的路径，并使用折线中的最后一个坐标作为令牌的新可到达位置。我的问题是，我可能必须同时向路线服务发布最多 30 个请求，并且我担心可能会达到查询速率限制。我还没有发现任何关于查询速率限制的明确信息。
所以我的问题是是否有人知道更好的解决方案或者可以提供有关方向查询速率限制的任何信息？在每个请求之间等待 1 秒并强制用户等待最多 30 秒并不是一个合理的解决方案。谢谢。
更新 使用我在问题中描述的解决方案确实会产生 OVER_QUERY_LIMIT，即使我在每个请求之间等待 1 秒也是如此。除此之外，逻辑是合理的，并且获得请求的令牌出现在步行可达的位置。
I have an application that generates some number of tokens around the current location of the user using a certain distance radius. The user will then have to run to some of those locations. The problem is that some tokens can be created in a lake,forest,ocean, or some other physically unreachable location. As a quick fix I just generate extra tokens and increase the proximity distance that determines if a user reached a certain location. I now want to improve this so that each token is located at a reachable location.
The only solution I have been able to come up with is using the Google Directions API to determine a path from the user to the token and use the last coordinate in the polyline as the new reachable location of the token. My problem with this is that I potentially have to post up to 30 requests to the Directions service simultaneously and I am worried that I might hit the query rate limit. I have not found anything definite about query rate limit.
So my question is whether anyone knows of a better solution or can give any input on the Directions query rate limit? Waiting 1 second between each request and forcing the user to wait up to 30 seconds is not a reasonable solution. Thanks.
UPDATE
Using the solution that I described in the question does produces an OVER_QUERY_LIMIT, even if I wait 1 second between each request. Other then that the logic was sound and tokens that got a request thru were appearing in walk reachable locations.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以使用 Location.distanceBetween() 计算两个纬度/经度之间的距离。这是一个静态便捷 API 调用。计算次数没有限制。
You can calculate the distance between two lat/lon with Location.distanceBetween(). This is a static convenience API call. There's no limit on number of calulations.
使用限制
您可能想了解一下地图高级客户，这样您就不会太快达到限制。如果您的应用程序变得流行，我打赌您可以获得更高的限制。
一种方法是看看是否可以看到海拔，以确定它是否是悬崖。然而，仅仅判断它是否是一个湖似乎很难。除了 Google 地图之外，可能还有某种 GPS 查找服务。
如果您只想知道位置之间的距离，只需使用 Location.distanceTo() 或 static
Usage limits
You might want to take a look into the Maps premier customer so you don't hit the limit too fast. If your app becomes popular I bet you can get an higher limit.
One way would be to see if you can see the elevation to see if it's a cliff or not. However just seeing if it's a lake or not seems to be quite hard. Might be some kind of gps lookup service out there except Google Maps.
If you just want to know the distance between locations just use Location.distanceTo() or static distanceBetween()
Getting the info if it's a road or not is another question.
大约 8 个小时后，我终于有了一些工作。因此，利用每个请求最多可以有 8 个航路点这一事实，从技术上讲，我可以在一个请求中询问前往 9 个位置的路线。这就是我现在正在做的事情：
一次生成 9 个随机位置。将位置传递给我的 DirectionsComputer，它返回经过所有 9 个坐标的折线路径作为坐标列表。然后我从路径中选择 9 个位置并将它们设置为我的令牌的位置。现在我所有的代币都是半随机生成的，总是出现在一条路上，我只需要连续 4 次请求就可以生成 36 个代币。
在某些情况下，一些令牌会聚集在一起。例如，最初位于海洋中的坐标被移动到同一个海滩。但在大多数情况下，我的所有测试都显示令牌分散开来，我可以调整其余部分。
After some 8 hours I finally got something working. So using the fact that each request can have up to 8 waypoints I can technically ask directions to 9 locations in one request. Here's what I am doing now:
Generate 9 random locations at a time. Pass the locations to my DirectionsComputer which returns the polyline path that goes through all 9 coordinates as a list of coordinates. Then I pick 9 location from the path and set them as the locations of my tokens. Now all my tokens are semi-randomly generated, always appear on a road, and I only need to do 4 consecutive requests to generate 36 tokens.
There are some cases where a few tokens are bunched together. For example, the coordinates which are originally located in the ocean get moved to the same beach. But for the most part, all my tests showed the tokens spread apart and I could tweak the rest.