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)

Обратите внимание, что все эти местоположения извлекаются с помощью получитьПоследнееИзвестноеМестоположение(). Что здесь кажется подозрительным, так это то, что первое и последнее местоположение идентичны (даже в других атрибутах), если быть более точным:

* 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), то зачем телефону подключаться к «дальней» вышке, если он видел более близкие вышки?

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


android location android-location
person NemoOudeis    schedule 11.07.2013    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

person user2598524    schedule 19.07.2013
comment
это, вероятно, правильно... Но для пользователей я хотел бы отфильтровать эти фиктивные исправления (за последнюю неделю я наблюдал более экстремальные примеры этого). Но я не вижу способа определить старые исправления, кроме сохранения старого местоположения в памяти и проверки их вручную, чего я бы предпочел не делать. - person NemoOudeis; 24.07.2013

arrow_upward
0
arrow_downward

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

Об этом много тем, в том числе и моя :(

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

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

person Mathias    schedule 01.10.2013
comment
Я добавил несколько фильтров и проверок работоспособности перед использованием местоположений, что значительно улучшило производительность моего приложения. Больше всего я столкнулся с тем, что API давал мне старые местоположения вышек сотовой связи (точность > 500), что мешало моему отслеживанию. Чтобы избежать этого, я начал группировать местоположения вышек сотовой связи и фильтровать новые вышки сотовой связи, которые лежат в этих кластерах (места, используемые для создания кластеров, периодически удаляются). Может это поможет - person NemoOudeis; 07.10.2013
comment
Вау, так ты хранишь базу данных по идентификаторам вышек сотовой связи? Это много хлопот для чего-то, что действительно должно работать... :( - person Mathias; 13.10.2013
comment
Я не использую для этого БД, так как мобильный контекст очень изменчив, места старше 1 часа забываются. Но вы правы, я был бы намного счастливее, если бы все сработало так, как я надеялся. - person NemoOudeis; 15.10.2013
comment
В итоге я просто никогда не запрашивал последнее кешированное местоположение. Нашему приложению всегда просто нужно действительно новое местоположение, но, поскольку оно кажется неустойчивым, мы всегда запускаем и подключаем клиент и начинаем активно опрашивать, пока не получим его, а затем снова выключаем. До сих пор мы видели только эти устаревшие местоположения, когда спрашивали через lastknownlocation. Пользовательский опыт пострадает, но что делать... - person Mathias; 15.10.2013

arrow_upward
0
arrow_downward

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

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));
person Douglas Daseeco    schedule 13.03.2017