Да, дурацкое округление. Но зачем? Это помогает как-то быстрее рендерить треки на экране? Быстрее проводить вычисления, если все точки привязаны к сетке? Интересно, это фича или баг?
Возможно, что если создатель использует приложение на автомобиле (или не для точного рисования а для навигации) - такое округление может и не сильно заметно (не мешает)?
предполагаю, что ограничения точности приёмника/точности сигнала, при котором запись с точностью до 0,0000001 градуса (upd - около 1 см в случае широты) становится бессмысленной - там все равно рандомное число будет. ИМХО.
petrovnn тут есть тэг code, стоило использовать именно его, чтобы привести листинги треков, не надо это постить в виде картинок.
Собственно, что и требовалось доказать - все вышеприведенные проблемы связаны с округлением, которое на практике приводит к тому, что точки оказываются в узлах сетки с шагом, равным величине дискретности.
Я был в этом с самого начала уверен, потому что лично мне не известен ни один пример софта, который бы проявлял столь бессмысленное поведение (как вы предположили), зато ситуаций с большим шагом дискретности видел сколько угодно. Например, слои в формате Garmin IMG именно таким образом организованы - каждый слой имеет меньший шаг дискретности, чем предыдущий. Так что ваши предположения были весьма странными, если не сказать конспирологическими.
Конкретно в вашем случае дискретность составляет около 20 сантиметров вдоль линий широты, чуть больше должно быть вдоль меридиана. Это, может быть, не так красиво выглядит, как более ровный трек, однако смысла в такой точности уже просто нет.
А про совпадение точек у orux и андрозика, смысл вот какой:
Если у андрозика те точки, которые он соизволяет записать, находятся на точно тех же местах, на которых они у oruxmaps, это означает, что он подвержен и округлению и пропуску одновременно. Иначе там не было бы этих (3) (6) (9).
Вывод из этого простой - обе программы пишут то, что приходит к ним на вход. Значит, уже ваш приемник так или иначе выдает вам вот это (или данные оказываются округлены по дороге от приемника до приложения). Так что нечего пенять на приложения, скорее всего.
Видите - корректно поставленный эксперимент все расставляет на свои места и не дает простора для измышлений.
Согласен со всем кроме одного:
Если-бы округление не убивало важные данные, я-бы согласился.
Еще раз приведу пример. Я обошел автомобиль петлей, записывая трек одновременно в двух программах (андрозик, орукс), обе программы стояли на одном телефоне и получали координаты от одного приемника. Вот автомобиль зелененький получился (колеса кривоваты но это ограничение joxi)
неужели вы скажете что данные которые были “убиты” округлением в этом треке “не важные”?
Точность трека андрозика (на глаз) составляет 30-40 см. Орукс эту “избыточную” точность уменьшил до 3 метров WTF?
мне кажется дело не в том, нужна-ли точность в 1 см или нет.
А в том что я не понимаю зачем автор программы так сильно округляет.
Уверен у него было обоснование для такого округления, какое именно - сказать уже не могу. Остается только спросить лично у него.
Потому что приемник выдает фиксированое количество знаков после запятой. Формат NMEA. О чем и говорили выше.
6 знаков после запятой = 0.11м по широте (примерно)
думая над причинами округления, нашел два возможных варианта:
1). меньшее количество точек позволяет на порядок быстрее рендерить записанный трек на экране (хотя на самом деле маловероятно, ведь в логе я видел что точки ставятся все равно каждую секунду. Но может при рендере одинаковые точки объединяются и все равно рендерится быстрее? У андрозика по умолчанию включено отображение xx количества последних точек текущего трека - очень удобно, можно отдельной кнопкой показать все точки трека. Все равно весь трек на телефоне просматриваю редко)
2). если каждая координата содержит меньше цифр - файл с координатами занимает меньше места
ну и вообще причины могут быть для меня не очевидны, т.к. в программе тонны других функций, некоторые из которых могли повлиять на принятие такого решения.
Короче причинно-следственной связи я скорее всего не понимаю.
а вы заставили меня обратить внимание на длину цифр после запятой.
Посмотрел исходник, действительно:
ORUX
<trkpt lat="57.80588" lon="28.343284999999998">
<ele>23.07</ele>
<time>2014-06-20T18:22:07Z</time>
</trkpt>
ANDROZIC
<trkpt lat="57.80586666666667" lon="28.343324999999997">
<ele>23.9</ele>
<time>2014-06-20T22:23:13Z</time>
</trkpt>
Видно что lat у орукса округлено до пяти цифр после запятой. Lon - 15 цифр. У андрозика по 15 и lat и lon.
Получается координаты искусственно деградируются до метровой/двухметровой точности.
Вашему телефону/приемнику и до такой точности еще расти и расти…
Challenge accepted
petrovnn
Вы в своем примере с автомобилем кроме того, что действительно забываете о реальных возможностях приемника, так еще и путаете две проблемы.
Я еще раз повторю: кроме округления до сетки с шагом в единицы десятков сантиметров из-за числа знаков после запятой, у вас еще наблюдается банальное упрощение трека либо по времени, либо по расстоянию. Красный трек на картинке с машиной упрощен, а не только точки в нем округлены. Я вам говорил только об округлении. Упрощение трека (запись одной точки не раз в секунду, а раз в пять или десять секунд, либо следующей точки не ближе, например, пяти метров) - это отдельная история.
А координаты у вас везде округлены, потому что вот это в скобках 28.343324(99999999)7 уже не значащая часть, а какой-нибудь случайный эффект от преобразования типов, потому что эти цифры у вас уже принимают только три значения - (3) (6) (9)
“Точность определения местоположения.
Записывать местоположение по GPS, если точность лучше, чем”.
Вроде всё совершенно понятно и ИМХО так и работает. За что “совершенно другое” по Вашему отвечает этот параметр?
Эцелоп потрудитесь перечитать сообщение, которое частично процитировали, полностью. То, как это сформулировано в программе сейчас, звучит, как минимум, не по-русски. То, что он сформулирован неправильно, доказывает ваш же совет, потому что прерывание записи трека, если точность хуже стольких-то метров (это то, за что отвечает эта настройка) никак не связано с фильтрацией вообще (о которой в своем совете относительно этого пункта говорили вы), прерывание это не фильтрация. А значит, менять этот параметр для получения иного результата - бесполезно. Если бы название было сформулировано верно, то вы бы таких советов не давали.
petrovnn, раз вы упомянули Garmin etrex, на вашем месте я бы от него не отказывался: писать трек обоими устройствами одновременно, “в поле” мониторить на смартфоне с любой из программ (что больше нравится), а на компьютере обрисовывать трек Гармина.
Для сравнения ещё нужно записывать не обработанные данные с GPS приемника (те что в NMEA формате приемник передает) - это будет самый правдивый трек, которого не коснулись никакие оптимизации и API.
И писать разработчикам программ, что бы убрали все округления.
kastellano - вообще-то не все девайсы на Андроиде умеют давать доступ к NMEA. Некоторые пускают только через location API. Проверить можно https://play.google.com/store/apps/details?id=com.mephisto.nmearecorder
BushmanK, программы “bluetooth gps provider” (которые используются для подключения внешнего приемника) разве не могут записать сырые данные с приемника?
Посмотрел описание трех таких программ в маркете - такой функционал не заявлен. Знаете такую, у которой это есть?
BushmanK, у меня вот эта работает/записывает.
https://play.google.com/store/apps/details?id=com.globalsat.android.gps.bluetooth.provider&hl=ru
Борцам с энтропией поем мы песню.
Покажите мне такой телефон, который гарантирует точность в 1 метр.