ГЛОблинНАСС

[Lev G.]

VPom писал(а) Mon, 19 November 2012 09:25

Вот еще один пример.

Красный трек - то, что получено с прибора. Синий - обработанный по некоторому специальному алгоритму.

Здесь мы видим классический пример "дрифта". Был прокол камеры. Пока клеился, прибор был неподвижен, а записанный им трек "гулял" вокруг прибора. С такими артефактами научился бороться более-менее эффективно (не на 100%, но в большинстве случаев выявлять их умею). Не так это и просто на самом деле. Визуально-то они сразу в газа бросаются, а вот математически выделить их оказалось достаточно нетривиально.

Я могу дать вам хороший совет как в принципе избежать подобных "дрифтов" на будущее.
Для этого в настройках пути выберите метод записи "расстояние" или даже "авто", но только не "время". Тогда на треке точек ближе 10м (а это как раз и есть типичное максимальное значение погрешности для современных приборов) друг от друга не будет. Трек будет "гулять" при остановке только при условии очень плохого приема сигнала.

[Bulawka]

Lev G. писал(а) Mon, 19 November 2012 18:39

Я могу дать вам хороший совет как в принципе избежать подобных "дрифтов" на будущее.
Для этого в настройках пути выберите метод записи "расстояние" или даже "авто", но только не "время". Тогда на треке точек ближе 10м (а это как раз и есть типичное максимальное значение погрешности для современных приборов) друг от друга не будет. Трек будет "гулять" при остановке только при условии очень плохого приема сигнала.

Спасибо за хороший совет.
Правда, он не настолько хорош. У меня всегда стоит "авто", при этом, например, хождение вокруг авто на открытой полянке
(пока авто греется, скажем, складываем вещи, переодеваемся)
пишется в виде звезды такой туда сюда.
Хотя мои перемещения в пространстве существенно меньше 10 метров.

[Lev G.]

Bulawka писал(а) Mon, 19 November 2012 18:48

Спасибо за хороший совет.
Правда, он не настолько хорош. У меня всегда стоит "авто", при этом, например, хождение вокруг авто на открытой полянке
(пока авто греется, скажем, складываем вещи, переодеваемся)
пишется в виде звезды такой туда сюда.
Хотя мои перемещения в пространстве существенно меньше 10 метров.

"авто" - это комбинированный способ записи трека, т. е. когда скорость маленькая точки ставятся реже, а когда выше чаще. Для меня также этот способ записи наиболее привлекателен, т. к. он не дает много лишних точек при остановке(в отличии от выбора метода "время") и в то же время достаточно подробно рисует трек при больших скоростях при этом ставятся точки в важных местах поворота (в отличие от метода "расстояние"). Метод "авто" конечно 100% не защищает от "дрифтов" (ведь даже сам навигатор, за 2ч моей остановки насчитывает примерно 1км пути и 35м набора высоты ), но во всяком случае существенно уменьшит количество вылетевших точек.
Близкую к 100% гарантию может дать только метод "расстояние" Изменено 19 ноября 2012 г. пользователем Lev G.

[al1]

Michael_L писал(а) Fri, 09 November 2012 19:40

VORON писал(а) Thu, 08 November 2012 21:08

Можно спросить у Аладина, какой софтиной он пользовался, чтобы считать графики доступности GPS и ГЛОНАСС.

Я вот только сомневаюсь, что Ал1 ответит

А почему?

[indi]

al1 писал(а) Thu, 22 November 2012 21:32

Michael_L писал(а) Fri, 09 November 2012 19:40

VORON писал(а) Thu, 08 November 2012 21:08

Можно спросить у Аладина, какой софтиной он пользовался, чтобы считать графики доступности GPS и ГЛОНАСС.

Я вот только сомневаюсь, что Ал1 ответит

А почему?

потому что с Sun, 10 July 2011 17:45 это первое сообщение от юзера под ником al1

[al1]

indi писал(а) Thu, 22 November 2012 21:52

al1 писал(а) Thu, 22 November 2012 21:32

Michael_L писал(а) Fri, 09 November 2012 19:40

VORON писал(а) Thu, 08 November 2012 21:08

Можно спросить у Аладина, какой софтиной он пользовался, чтобы считать графики доступности GPS и ГЛОНАСС.

Я вот только сомневаюсь, что Ал1 ответит

А почему?

потому что с Sun, 10 July 2011 17:45 это первое сообщение от юзера под ником al1

Жуть

[Michael_L]

al1 писал(а) Fri, 23 November 2012 01:22

indi писал(а) Thu, 22 November 2012 21:52

al1 писал(а) Thu, 22 November 2012 21:32

Michael_L писал(а) Fri, 09 November 2012 19:40

VORON писал(а) Thu, 08 November 2012 21:08

Можно спросить у Аладина, какой софтиной он пользовался, чтобы считать графики доступности GPS и ГЛОНАСС.

Я вот только сомневаюсь, что Ал1 ответит

А почему?

потому что с Sun, 10 July 2011 17:45 это первое сообщение от юзера под ником al1

Жуть

С возвращением!

[RaFaeL]

О, специалисты по GPS и матану ))
А можете вот такое объяснить?
Вот то место, где как бы два трека идут как бы параллельно - это на самом деле одна и та же дорога. Из-за чего такая ошибка набежала? Навигатор Dakota 10
Изменено 23 ноября 2012 г. пользователем RaFaeL

[al1]

RaFaeL писал(а) Fri, 23 November 2012 11:21

Вот то место, где как бы два трека идут как бы параллельно - это на самом деле одна и та же дорога. Из-за чего такая ошибка набежала? Навигатор Dakota 10

1. сколько в метрах расстояние между треками?
2. треки "туда" и "обратно" насколько по времени разнесены?
3. по бокам от дороги там что? вероятно лес? Если да, то какой (лиственный или хвойный, сырой или сухой)?
Изменено 23 ноября 2012 г. пользователем al1

[S.A.]

Michael_L писал(а) Fri, 23 November 2012 09:09

al1 писал(а) Fri, 23 November 2012 01:22

indi писал(а) Thu, 22 November 2012 21:52

al1 писал(а) Thu, 22 November 2012 21:32

Michael_L писал(а) Fri, 09 November 2012 19:40

Я вот только сомневаюсь, что Ал1 ответит

А почему?

потому что с Sun, 10 July 2011 17:45 это первое сообщение от юзера под ником al1

Жуть

С возвращением!

Да, Алексей, с возвращением!
Ура, Аладин вернулся!

[al1]

S.A. писал(а) Fri, 23 November 2012 20:29

Да, Алексей, с возвращением!
Ура, Аладин вернулся!

Ага, я такой

[pr]

+1 к С возвращением!

[Lev G.]

VPom писал(а) Sat, 17 November 2012 11:59

Lev G. писал(а) Sat, 17 November 2012 01:57

Так можно ведь написать такую программу, чтоб пользователь сам задавал в программе это число. Скажем если он знает, что он более 40км/ч не ехал, выставит допустим 45 в фильтре, а если это скоростной даунхилл, то большее число. После этого программа начнет работу.

Хорошо. Значит 44.99 - не выброс, а 45.01 - выброс?
вы сами хоть одну такую программу написали? Думаю что нет. А я несколько лет этим вопросом в свободное время занимаюсь. Не так там все просто как кажется с первого взгляда.

Чтобы стало понятнее могу предложить "домашнее задание". возьмите трек, загрузите его, скажем, в эксель, и попробуйте рассчитать какой-то критерий для каждой точки трека, по которому можно было бы однозначно сказать выброс это или нет. Не видя трек на карте, просто по координатам-времени для каждой точки.

Если удастся, возьмите еще десяток-другой треков и проверьте найденный критерий на них.

Уважаемый VPom будем считать, что ваши многочисленные провокации в мой адрес сработали и я решил выполнить ваше "домашнее задание": написал программу TrackAnalizator для анализа треков формата *.plt и создания нового файла трека без "ошибок". (архив с программой во вложении)

Программа написана на языке Java и выполняется как приложение на ПК. Для работы приложения возможно дополнительно потребуется установить или обновить программное обеспечение java: http://www.java.com/ru/download/index.jsp

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

Программа позволяет выявлять "плохие" точки тремя разными методами.
1) Метод слабого сигнала заключается в том, что программа находит строки в треке, где был потерян сигнал и помечает на удаление 1 точку до и 3 после этого события.

Важным положительным эффектом от применения этого метода для пользователя является то, что он получает трек не разбитый на секции, а как одно целое. Просматривать его в MapSource будет гораздо приятнее
2) Метод отрезков заключается в том, что на отрезке из 4 точек сравниваются расстояние между крайними и между ближайшими точками. Если расстояние между крайними точками меньше чем между ближайшими точка помечается на удаление.

К сожалению я не могу в полной мере оценить корректность его работы, т. к. треков с большими "дрифтами" нет.

Конечно мой метод примитивен и тут я согласен с вами, есть огромный потенциал для творчества, можно учитывать азимуты точек, аппроксимацию... Если будет время можно попробовать вместе найти "идеальное" решение.

3) Метод "нереальных" скоростей + дополнительная опция, возможность пользователю установить самому критерий удаления точек.

Это тот метод в эффективности которого я убедился уже давно. Тем кто не верит предоставляется возможность проверить его на своих треках

Максимальное число точек трека для анализа в файле трека - 20 тыс шт. (не хотелось выделять черезмерно большие объемы памяти под массивы)

Окно программы:


Тот же файл после обработки:

Изменено 28 ноября 2012 г. пользователем Lev G.

[HeavY]

al1 писал(а) Fri, 23 November 2012 21:23

S.A. писал(а) Fri, 23 November 2012 20:29

Да, Алексей, с возвращением!
Ура, Аладин вернулся!

Ага, я такой

C возвращением! Изменено 28 ноября 2012 г. пользователем HeavY

[Santa]

Lev G. писал(а) Wed, 28 November 2012 18:23

Уважаемый VPom будем считать, что ваши многочисленные провокации в мой адрес сработали и я решил выполнить ваше "домашнее задание": написал программу TrackAnalizator для анализа треков формата *.plt и создания нового файла трека без "ошибок". (архив с программой во вложении)...

Lev G., а как же стандартный ныне формат gpx?

[VPom]

Что-то не запускается у меня. Стоит Java 1.6.0_37 - другие аплеты запускаются без проблем, а этот ругается на то, что не может найти какой-то класс.

plt - это плохо Нет у меня таких треков готовых. все в стандартном gpx (озиком не пользуюсь, давно ушел на OkMap, навигатор - Магеллан - пишет напрямую в gpx, логгер пишет в nmea, потом в gpx конвертирую).

Так что проверить быстро не получилось, увы...

[VORON]

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

[VPom]

Lev G. писал(а) Wed, 28 November 2012 20:23

1) Метод слабого сигнала заключается в том, что программа находит строки в треке, где был потерян сигнал и помечает на удаление 1 точку до и 3 после этого события.

Важным положительным эффектом от применения этого метода для пользователя является то, что он получает трек не разбитый на секции, а как одно целое. Просматривать его в MapSource будет гораздо приятнее

1. А что такое MapSource?
2. Как вы определяете "слабый сигнал"? У вас есть в треке информация и количестве видимых спутников/спутников, по которым принимается решение, или хотя бы, HDOP?
3. Почему именно "одна до и три после"?

Lev G. писал(а) Wed, 28 November 2012 20:23

2) Метод отрезков заключается в том, что на отрезке из 4 точек сравниваются расстояние между крайними и между ближайшими точками. Если расстояние между крайними точками меньше чем между ближайшими точка помечается на удаление.

К сожалению я не могу в полной мере оценить корректность его работы, т. к. треков с большими "дрифтами" нет.

Конечно мой метод примитивен и тут я согласен с вами, есть огромный потенциал для творчества, можно учитывать азимуты точек, аппроксимацию... Если будет время можно попробовать вместе найти "идеальное" решение.

Почему именно 4 точки? Могу вам накидать треков с логгера, там есть участки с частотой записи 5 точек в секунду

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

Вот вам навскидку трек. В архиве plt в том виде, как он получен с логгера, htm - как он должен выглядеть на самом деле.

Я эту задачку решить не смог пока.

[anviczhukov]

VPom писал(а) Thu, 29 November 2012 12:29

Вот вам навскидку трек.

Такой трек обрабатывать - просто безумие!

[VPom]

anviczhukov писал(а) Thu, 29 November 2012 16:05

VPom писал(а) Thu, 29 November 2012 12:29

Вот вам навскидку трек.

Такой трек обрабатывать - просто безумие!

А более простые треки обрабатывать большого смысла нет. Выкинуть 1-2 точки проще всего руками в GPXEditor'е

[anviczhukov]

VPom писал(а) Fri, 30 November 2012 12:17

anviczhukov писал(а) Thu, 29 November 2012 16:05

VPom писал(а) Thu, 29 November 2012 12:29

Вот вам навскидку трек.

Такой трек обрабатывать - просто безумие!

А более простые треки обрабатывать большого смысла нет. Выкинуть 1-2 точки проще всего руками в GPXEditor'е

Да такой трек с погрешностью более км тоже обрабатывать смысла нет. Проще от руки нарисовать, точнее будет!

[VPom]

anviczhukov писал(а) Fri, 30 November 2012 14:32

VPom писал(а) Fri, 30 November 2012 12:17

anviczhukov писал(а) Thu, 29 November 2012 16:05

VPom писал(а) Thu, 29 November 2012 12:29

Вот вам навскидку трек.

Такой трек обрабатывать - просто безумие!

А более простые треки обрабатывать большого смысла нет. Выкинуть 1-2 точки проще всего руками в GPXEditor'е

Да такой трек с погрешностью более км тоже обрабатывать смысла нет. Проще от руки нарисовать, точнее будет!

Да нет, там просто ряд точек надо скорректировать.

[Lev G.]

Santa писал(а) Thu, 29 November 2012 08:42

Lev G., а как же стандартный ныне формат gpx?

Тоже думал над этим. Были несколько причин по которым я решил начать писать программу сначала для plt формата, а не gpx.
Во первых время, которое очень важно для расчета расстояния, а затем и скорости в plt формате находиться в абсолютных единицах с погрешностью примерно 0.01с Это довольно неплохо. В случае с gpx форматом погрешность 1с, что в 100 раз больше. Правильнее сначала проверить программу на более точных данных.

Во вторых для gpx формата мне пришлось бы писать отдельный метод для перевода времени в абсолютные единицы. Уйти от формата ДД:Мес:ГГ ЧЧ:ММ:СС чтобы сравнивать время. Это отняло бы лишнее время для написания программы.

В третьих я пользуюсь версией Ozi которая не поддерживает просмотр треков в ином формате кроме plt. А Ozi в отличии от других программ выдает подробную статистику по точкам, удобно сравнивать его расчеты с теми что выполнила моя программа.

В четвертых любой из форматов можно легко конвертировать в другой. Например тот же gpx в plt. Проанализировать его, а затем обратно или в gpx или в популярный нынче kml(для просмотра на спутниковом снимке) кому как нравиться.

Конечно программу можно дописать, чтобы она понимала и gpx формат или еще какой-то другой. Просто методы обработки строк файла будут совсем иными. Будет время возможно займусь и этим.

[VPom]

Lev G. писал(а) Fri, 30 November 2012 16:22

Во первых время, которое очень важно для расчета расстояния, а затем и скорости в plt формате находиться в абсолютных единицах с погрешностью примерно 0.01с Это довольно неплохо. В случае с gpx форматом погрешность 1с, что в 100 раз больше. Правильнее сначала проверить программу на более точных данных.

Если вы работает с треком, записанным с навигатора, то там в любом случае точность будет не выше 1с. Навигаторы точнее не умеют. А елси логгер, то и в gpx время может писаться с высокой точностью:

<time>2012-04-06T01:50:28.799Z</time>

Lev G. писал(а) Fri, 30 November 2012 16:22

Во вторых для gpx формата мне пришлось бы писать отдельный метод для перевода времени в абсолютные единицы. Уйти от формата ДД:Мес:ГГ ЧЧ:ММ:СС чтобы сравнивать время. Это отняло бы лишнее время для написания программы.

А время и так и этак нужно переводить в нормальный вид. Например в Unixtime в расширенном варианте (т.е. не 32 бит целое, а с плавающей точкой где целая часть - стандартный Unixtime, а дробная - миллисекунды).

А gpx по сути есть обычный xml, парсеров готовых можно найти.

[Lev G.]

VPom писал(а) Thu, 29 November 2012 12:29

1. А что такое MapSource?
2. Как вы определяете "слабый сигнал"? У вас есть в треке информация и количестве видимых спутников/спутников, по которым принимается решение, или хотя бы, HDOP?
3. Почему именно "одна до и три после"?

1. MapSource - оффлайновая программа компании Garmin для работы с векторными картами. Распространяется бесплатно при покупке приборов Garmin. Соответственно есть у всех счастливых обладателей таких приборов.

2. Слабый сигнал(точнее его потерю) определяю по данным plt файла. В структуре plt файла это можно узнать по символу после 2 запятой. Если это "1" потеря сигнала, если "0" нет
Вот пример:
60.363370, 29.209070,1, 175.5,41049.2970833, 20-май-12, 7:07:48

В структуре gpx файла за это отвечает такая строка
</trkseg>
И соответственно начало новой секции
<trkseg>

В случае потери сигнала первые записи после этого как правило ошибочные (проверял на множестве треков) или точки аппроксимируются в то место в котором ты уже не находишься или время сбрасывается до дефолтного 21-авг-99 Причем проанализировав много треков пришел к выводу, что иногда перед полной потерей сигнала точка уже может вылететь на 1км.
В каждом треке это происходит по разному. Где-то 1 точка до этого и 3 после, где-то 0 точек до и 5 после ошибочные.
Есть общая закономерность, но 100% гарантию что метод выловит "плохую" точку я конечно дать вам не могу.

3. Удалять 1 точку до и 3 после потери сигнала такое решение принято мной на основе анализа общих закономерностей своих треков, где подобные ошибки встречаются в записи трека. Конечно для треклогера или прибора с плохим приемом сигнала допускаю что другие параметры могут быть здесь более правильными.
На данном этапе для меня было важно показать вам что программа эффективна и будет работать.