为什么 locationmanager 使用新的 gettime-timestamp 返回旧的位置修复?

发布于 2024-12-08 05:12:11 字数 780 浏览 4 评论 0原文

我们有一个应用程序,根据用户操作尝试获取位置修复。它在 GPS 和网络上监听,并具有基于时间/准确性的决策矩阵,以确定何时停止监听以及返回哪些修复。

有时,我们注意到一种非常奇怪的行为。我们使用经典的方法来查看修复的时间有多长,如下所示:

long age = now - newLocation.getTime();
if(age >= prefs.getLocationMaxAge()){
    Log.d(TAG, "location too old.");
    return;
}

但有时,根据返回的时间戳,从操作系统返回的 location.getTime 的年龄可能为 15-20 秒,尽管我们可以确定它很旧了。例如,如果经度/纬度定位来自手机 30 分钟前所在的位置!

似乎 Wi-Fi 和网络都会发生这种情况,但 GPS 不会发生这种情况。对我来说,这完全是疯狂的。有其他人看到过这个吗?有什么办法可以解决吗?

我们已经在几款不同的手机上安装了该功能,最近的一款是 三星 Galaxy S II

非常欢迎提供帮助。

编辑:要真正清楚的是,问题是操作系统调用“onlocationchanged”回调,其时间戳年龄可能为几秒,当我确定经度时“新”修复中的 /latitude 是手机至少 30 分钟没有出现过的地方。

这使得很难准确地确定手机的位置......

We have an app that upon user action tries to get a location fix. It listens both on GPS and network and has a time/accuracy based decision matrix to determine when to stop listening and what fix to return.

We have noticed, on occasion, a very strange behaviour. We use the classic way to see how old the fix is, like so:

long age = now - newLocation.getTime();
if(age >= prefs.getLocationMaxAge()){
    Log.d(TAG, "location too old.");
    return;
}

But sometimes, the location.getTime returned from the OS has an age of perhaps 15-20 seconds, according to the returned timestamp, although we can tell for certain that it's very old. For example, if the longitude/latitude fix is from a position that the handset was on 30 minutes ago!

It seems to happen both from Wi-Fi and network, but not GPS. To me, this is totally crazy. Has anyone else seen this and is there any way around it?

We have gotten it on a couple of different phones, most recent one is Samsung Galaxy S II.

Help would be extremely welcome.

EDIT: To be really clear, the problem is that the "onlocationchanged" callback gets called by the OS with a location with a timestamp age of perhaps a couple of seconds, when I know for certain that the longitude/latitude in the "new" fix is a place where the phone hasn't been at for at least 30 minutes.

This makes it kind of hard to accurately determine where the handset it...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

赤濁 2024-12-15 05:12:11

Wi-Fi 和网络似乎都会发生这种情况,但 GPS 不会发生

这似乎很公平,因为在基于 Wi-Fi 和网络蜂窝基站的三角测量中,精度非常差。他们可能正在使用可追溯到 30 分钟前的缓存位置。除非您没有更改您的蜂窝基站或移动到另一栋建筑物,以便可以发现新的AP ,恐怕您只会获得缓存的位置。如果您想要新的位置,请使用 GPS 提供商。

It seems to happen both from Wi-Fi and network, but not GPS

This seems fair, because in the Wi-Fi and network cell-site based triangulation, the accuracy is very bad. They are probably using cached locations which date back to 30 minutes ago. Unless you have not changed your cell-site or moved to another building so that new APs can be discovered, I'm afraid you will get only cached locations. If you want fresh locations use the GPS provider.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文