Android LocationClient.getLastLocation() возвращает старое и неточное местоположение с новой отметкой времени

Я пользуюсь провайдером слияния с момента его выпуска и очень доволен им (намного лучше, чем старая система). Но я столкнулся с особой проблемой при использовании геозоны в сочетании с 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, но этот новый поставщик местоположения просто называется fusedпоэтому я не могу отличить GPS от WPS от датчиков... Если это проблема переключения вышек сотовой связи (обрисованная в общих чертах в связанном вопросе о старом API), то зачем телефону подключаться к "далекой" вышке, если он видел ближе башни?

Почему это происходит?

Источник

3 ответа

Первый и последний баллы были получены с помощью триангуляции клеток. Ошибка / точность типичны для местоположения на основе ячейки, и похоже, что логика энергосбережения Google решила, что переключение на ячейку будет в порядке, даже если вы говорите, что его недавняя история включала точки гораздо ближе.

Источник

Вместо опроса, можно использовать один или несколько источников неточностей, используя этот механизм подписки.

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));
Источник

Ой, ШУКС! Я тоже получил это сегодня... И я переехал в новое местоположение Служб Google Play именно для того, чтобы ИЗБЕГАТЬ этого... И я был так взволнован до тех пор, пока не получил его тоже. Вы можете знать или не знать, что у старого были такие проблемы, и это была боль.

Есть много тем по этому поводу, включая мою собственную:(

Почему locationmanager возвращает старые исправления местоположения с новым gettime-timestamp?

Я думаю, единственное, что нужно сделать, это избегать использования кэшированного местоположения...

Источник
Другие вопросы по тегам