4

リリース以来、融合された位置情報プロバイダーを使用してきましたが、かなり満足しています (古いシステムよりもはるかに優れています)。しかし、ジオフェンシングを LocationClient.lastKnownLocation() と組み合わせて使用​​すると、奇妙な問題に遭遇しました。セットアップは次のとおりです。

いくつかのジオフェンスをいくつかのホーム ロケーションの周囲に配置します (範囲を増やします)。フェンスが交差しているという意図が得られたら、LocationClient から最後に認識された場所を取得し、それを操作します。それとは別に、更新モード PRIORITY_BALANCED_POWER_ACCURACY で定期的な位置情報の更新も登録しました。

ほとんどの場合、これで問題なく動作しますが、次のようなことが起こることがあります。

時間 000 秒 - (緯度、経度、精度) = (48.127316,11.5855167,683.0)

時間 120 秒 - (緯度、経度、精度) = (48.1260497,11.5731745,31.823)

時間 300 秒 - (緯度、経度、精度) = (48.1217455,11.5641666,143.81)

時間 420 秒 - (緯度、経度、精度) = (48.1189942,11.559061,36.0)

時間 600 秒 - (緯度、経度、精度) = (48.127316,11.5855167,683.0)

これらの場所はすべてgetLastKnownLocation()によって取得されることに注意してください。ここで怪しいと思われるのは、より具体的に言うと、最初と最後の場所が (他の属性であっても) 同じであることです。

* intent at time 0: *

component: ComponentInfo{package.Class}
key [location]: Location[mProvider=fused,mTime=1373524391934,mLatitude=48.127316,mLongitude=11.5855167,mHasAltitude=false,mAltitude=0.0,mHasSpeed=false,mSpeed=0.0,mHasBearing=false,mBearing=0.0,mHasAccuracy=true,mAccuracy=683.0,mExtras=Bundle[mParcelledData.dataSize=352]]

* intent at time 600: *

component: ComponentInfo{package.Class}
key [location]: Location[mProvider=fused,mTime=1373524994871,mLatitude=48.127316,mLongitude=11.5855167,mHasAltitude=false,mAltitude=0.0,mHasSpeed=false,mSpeed=0.0,mHasBearing=false,mBearing=0.0,mHasAccuracy=true,mAccuracy=683.0,mExtras=Bundle[mParcelledData.dataSize=352]]

* note the ~600 s difference in the timestamp *

より最近でより正確な場所が間にあったため、これがどのように発生するのかわかりません。また、古い場所の新しいタイムスタンプも気になります...古い APIを使用したときに同様のことが起こったようですが、この新しい場所プロバイダーは と呼ばれているだけなので、GPS とWPSをセンサ​​ーfusedと区別することはできません...携帯電話基地局の切り替えの問題 (古い API に関するリンクされた質問で概説されています) では、電話が近くの塔を見た場合、電話が「遠くの」塔に接続するのはなぜですか?

なぜこうなった？

4

3 に答える 3

1

最初と最後のポイントは、セルの三角形分割を使用して取得されました。エラー/精度はセルベースの場所の典型であり、最近の履歴にははるかに近いポイントが含まれているとあなたが言ったとしても、Googleの省電力ロジックはセルへの切り替えがOKであると判断したようです.

于 2013-07-19T07:48:58.583 に答える
0

ああ、シャック！私も今日これを手に入れました...そして、まさにこれを避けるために、新しいGoogle Playサービスの場所に移動しました...そして、私もそれを手に入れた今までとても興奮していました. 古いものにこの種の問題があり、それが苦痛だったことを知っているかもしれませんし、知らないかもしれません。

これに関しては、私自身のものを含め、たくさんのスレッドがあります :(

locationmanager が古いロケーション修正を新しい gettime-timestamp で返すのはなぜですか?

私がすべき唯一のことは、キャッシュされた場所の使用を避けることだと思います...

于 2013-10-01T17:34:24.047 に答える
0

ポーリングの代わりに、このサブスクリプション メカニズムを使用して、1 つまたは複数の不正確な原因を回避できます。

LocationListener locListener = new LocationListener() {
    @Override
    public void onLocationChanged(Location location) {
        if (location == null)
            return;
        // process these:
        // location.getLatitude();
        // location.getLongitude();
        // location.getAccuracy();
        ...
    }
    ... 
}

((LocationManager) getSystemService(Context.LOCATION_SERVICE)
        .requestLocationUpdates(LocationManager.GPS_PROVIDER,
                minTimeMilliSec,
                minDistanceMeters,
                locListener));
于 2017-03-13T18:38:46.100 に答える