Честно говоря не знаю где еще можно задать подобный вопрос, по этому задаю здесь. Я уже много лет пишу треки и использовал для этого кучу разных устройств. После того как забыл свой трекер в прокатной машине стал писать треки телефоном Samsung Galaxy S5. Надо сказать, что он очень неплохо ловит сигнал, но очень странно пишет треки.
Дело в том что между соседними точками могут быть разные интервалы времени. Если я ставлю “записывать каждую секунду” то имею примерно следующее: 17:09.345, 10:17:10.344, 17:11.342, 10:17:12.366, 17:14.402 и т.п.
Вроде ничего особенного, стал допиливать поддержку таких треков на GPSLib. Но не тут то было. Даже с учетном разных интервалов получается дикий разброс в скоростях (последняя колонка). Алгоритм оценки качества трека считает такой трек некачественным и не загружает в OSM. И правильно делает, скорость нормального трека не может прыгать +/- 10 км/ч каждую секунду.
Вопрос. Что за фигня? Как так-то? Ниже отрывок GPS трека записанный на ровном участке при движении с одинаковой скоростью.
Это скорей время не GPS, а записи , а т.к. это целый компьютер, мало ли что он там ещё делает на процессоре, поэтому ожидать точность в 0.001 секунды от него глупо. Ну и считать мгновенную, секундную скорость как-то странно.
Надо сваливать не на прикладное ПО, а на систему. Ведь все программы получают данные из его API. Странно, что он вообще там копейки секунд пишет, мог бы с чистой совестью отрезать их до секунд.
Записывайте сырые данные с GPS приемника, в NMEA. Тогда никакие API и системы не будут влиять.
У меня в NMEA пишется целыми секундами, каждую секунду. На других (особенно кто чаще 1 раза в секунду определяет положения) возможно по другому, но предполагаю, что число будет ровное (т.е. для 2Гц всегда будет после запятой будут либо нули, либо .500, для 5Гц - 000/200/400/600/800).
Возможно необходимо определять частоту получения данных и округлять в меньшую сторону до ближайшего целого числа.
Какое приложение используется?
Да, в NMEA будет время с GPS приемника, а не с часов устройства, да и скорость оттуда же.
В андроиде есть API для получения NMEA даных, другое дело, что некоторые приложения его действительно формируют сами, нужно подбирать.
Впрочем, API андроида тоже обычно нормальную скорость отдает, а в логе она явно расстояние/время. И Timestamp 1432376233.365 странно в дату/время сконвертировался.
Наборот, 2015-05-23T10:17:09.345 сконвертировано в 1432376229.345. Что не так?
В качестве исходных данных взят KML записанный гугловской “Мои треки”. Там есть только координаты, высота и время.
Пробовал несколько других программ, история та же.
Вопрос не только как на андроиде получить нормальный трек, но и как правильно анализировать треки записанные пользователями андроида.
Если “пользователь Андроида” использует нормальный софт и его аппарат не имеет никаких проблем с выдачей более-менее честного NMEA, то никакие ухищрения для обработки такого трека не нужны.
Если “пользователь Андроида” не использует нормальный софт или у него есть какие-то иные проблемы, то его треки ни на что не годятся кроме как на них любоваться ему самому - фарш невозможно провернуть назад.
Если пользователь Андроида использует софт работающий через API (а это основное большинство) то координаты пишутся вполне точно, чего вполне достаточно для использования в OSM. NMEA дамперов раз два и обчелся, да и не пользуется ими никто.
Ну и по сути вопроса. Действительно, если использовать для записи трека NMEA дампер, то проблем нет. Похоже, что все же дело в API Андроида.
Ну вот вы сами сначала сказали, что API - это достаточно хорошо, а потом признали, что это плохо.
Я не знаю, нужны ли на gpslib треки с разбросом в сотни метров от реального положения и т.п., может и нужны, но в OSM, за редчайшим исключением, они не нужны совсем.
Это не такая простая задача, как кажется.
Представьте себе дерьмовый трек в традиционном стиле “машина едет по домам”.
Очевидно, что более приличные треки по домам не проходят.
Так что трек, который идет там, где треков быть вообще не должно, при проверке на несовпадение, эту проверку гарантированно пройдет. Проверять на пересечения с домами - полумера, потому что они физически есть не везде.
Также это не решает проблемы, когда часть трека - хорошая, а часть - мусор.
Единственным решением, которое может быть реально полезно (а не являлось бы супер-сложным костылем, который решает одну двадцатую часть проблемы), было бы добавление методов удаления и разделения треков на части в базе OSM. И какой-то wiki-подобной морды для этого.
Только тогда можно будет очистить базу от откровенного мусора, оставив строго то, что нужно, и при этом не бояться, что кто-то его туда добавит.
Да, фиг с ним, пусть по домам, куда большая польза от треков в глубинке, где и домов то нет и меньшая это третья сотня по транку.
Редактирование треков - это тема для какого нибудь гугльсамекоде. Я бы с лёгкостью отдал голос за неё, чем какая-то модерация что сейчас там пилиться.
Ну вот в том то и дело, что трек в пресловутой глубинке тоже должен быть более-менее похож на правду, а не плюс-минус 300 метров, иначе его смысл теряется.
Что до задачи для google summer of code - полностью согласен, тем более, это вполне ясная и несложная задача, а с модерацией и прочим есть куча вещей, которые неочевидны административно-идеологически, что превращает любое решение в малополезное.
