ГЛОблинНАСС

[indi]

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

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

не надо говорить за всю сеть

[Lev G.]

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

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

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

Да уж, это мягко говоря тяжелый случай Я бы такой трек сразу отправил в корзину.

Тем не менее проанализировал его своей программой. Кое что она все таки смогла для вас сделать. Обнаружила и удалила откровенные вылеты.
Вот результат ее анализа:

Ваш трек

Измененный трек

[Lev G.]

Вот измененный программой трек

[Lev G.]

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

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

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

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

Важно понимать, что это не апплет (программа которая помещаются на Web страницы), а приложение (самостоятельная программа выполняемая с использованием интерпретатора java). Т. е. запустить ее в окне браузера никак нельзя. Я для этого создал пусковой файл TrackAnalizator.bat Даже сам TrackAnalizator.jar может служить стартом для выполнения программы при правильно настроенных файловых ассоциациях на вашем ПК (по двойному щелчку на нем) .


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


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

[Frai]

vik_q писал(а) Tue, 13 November 2012 08:59

kampy писал(а) Mon, 12 November 2012 18:37

Илья вот тебе пример Российских производителей:
http://aggf.ru/arh/press.php?num_news=1651

прочел многабукф. ф шоке...
Россия такая Россия...

У меня шок давно прошел,
такое сейчас во всех отраслях.

[VPom]

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

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

Я себя отношу к счастливым необладателям сего прибора (вот уже почти полтора года как).

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

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

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

Могу вас заверить, что деление трека на секции никак не коррелирует с потерей сигнала. Тут возможны разные ситуации:

1. Прибор действительно начинает новую секцию при потере сигнала.
2. Прибор никак не отмечает потерю сигнала и вообще никоим образом не поддерживает секции в треке
3. Прибор закрывает текущий трек и начинает новый при потере сигнала.
4. Прибор делит трек на секции по своим внутренним соображениям. Например, по количеству точек. Или по истечении некоторого времени. Или... да бог его знает почему.

Так что привязываться к сегменту трека как к точке потери сигнала некорректно.

Я не говорю о таких ситуациях как:

Выключили запись трека (не выключая прибора), отошли на километр, включили снова.
Скачали (или обработали) трек какой-то программой, которая все сегменты объединила в один.

Вобщем, вы закладываетесь на обработку очень частных случаев, характерных для вашего прибора и ваших настроек. В то время как на самом деле программа должна сама искать "особые точки", исходя из того, что они чем-то отличаются от остальных (соседних).

[VPom]

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

Да уж, это мягко говоря тяжелый случай Я бы такой трек сразу отправил в корзину.

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

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

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

Тем не менее проанализировал его своей программой. Кое что она все таки смогла для вас сделать. Обнаружила и удалила откровенные вылеты.
Вот результат ее анализа:

Часть вылетов таки да. А вот большую часть она таки пропустила. Хотя первый (внизу) пик - откровенный вылет. Пила в правом верхнем углу - похоже на дрифт. Перед ней - вылет на несколько точек.

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

[Lev G.]

VPom писал(а) Mon, 03 December 2012 10:04

К сожалению, это вполне нормальный трек для города.

VPom писал(а) Mon, 03 December 2012 09:46

Я себя отношу к счастливым необладателям сего прибора (вот уже почти полтора года как).

Вот когда вы превратитесь из счастливого необладателя в обладателя прибора Garmin (на сирф-3 или мтк), видимо тогда вы перестанете считать подобные треки нормальными для города.

Это не реклама Гармин, возможно что и другие производители делают нечто подобное. По крайне мере 60 серия и eTrex (не совсем древние) с такой огромной погрешностью треки в городах да и вообще где бы то ни было(за исключением разве что глубоких каньонов) не рисуют.

[VPom]

Lev G. писал(а) Tue, 04 December 2012 14:06

Вот когда вы превратитесь из счастливого необладателя в обладателя прибора Garmin (на сирф-3 или мтк), видимо тогда вы перестанете считать подобные треки нормальными для города.

Это не реклама Гармин, возможно что и другие производители делают нечто подобное. По крайне мере 60 серия и eTrex (не совсем древние) с такой огромной погрешностью треки в городах да и вообще где бы то ни было(за исключением разве что глубоких каньонов) не рисуют.

Я был обладателем "не совсем древнего" Garmin eTrex H (то же поколение, что и Legend HCx). И в городе он рисовал не менее затейливо. Магеллан, кстати, в этом отношении более аккуратен - у них еще со времен старого чипсета (TrueFix) весьма неплохие внутренние алгоритмы обработки. Ну и вылетов трека в космос при замене батарейки они точно не страдают.

А мне приходится работать с теми данными, которые предоставил заказчик. И как-то выкручиваться.

[indi]

кстати, для мегелланов в версии 1.60 Qlandkarte GT добавили поддержку rmp
http://mac.softpedia.com/progChangelog/QLandkarte-GT-Changelog-54425.html

[Lev G.]

VPom писал(а) Mon, 03 December 2012 09:46

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

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

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

Могу вас заверить, что деление трека на секции никак не коррелирует с потерей сигнала. Тут возможны разные ситуации:

1. Прибор действительно начинает новую секцию при потере сигнала.
2. Прибор никак не отмечает потерю сигнала и вообще никоим образом не поддерживает секции в треке
3. Прибор закрывает текущий трек и начинает новый при потере сигнала.
4. Прибор делит трек на секции по своим внутренним соображениям. Например, по количеству точек. Или по истечении некоторого времени. Или... да бог его знает почему.

Так что привязываться к сегменту трека как к точке потери сигнала некорректно.

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

Привязываться к сегменту трека можно и нужно для удаления ошибочных данных.
Более того программа OziExplorer которую писали надо полагать не совсем дураки именно это и делает при подсчете статистики, т. е. она не учитывает данные расстояния и скорости в местах начала новой секции. Если трек по каким то причинам не имеет секций(например секции были объединены в одну другой программой или сигнал не был потерян, но был так слаб, что имел огромную погрешность) как в вашем примере, то все "нереальные" скорости и расстояния попадают в статистику трека подведенную этой программой.

Эту особенность я и решил использовать в алгоритме своей программы. Чтобы не только статистика не искажалась (как в Ozi), но еще и подобные точки удалялись из трека за ненадобностью. А измененный трек и выглядел бы более правдоподобно и статистика любыми другими программами (даже без такого механизма защиты как в Ozi) велась верно.

[VPom]

indi писал(а) Tue, 04 December 2012 14:31

кстати, для мегелланов в версии 1.60 Qlandkarte GT добавили поддержку rmp
http://mac.softpedia.com/progChangelog/QLandkarte-GT-Changelog-54425.html

Спасибо, интересно. Надо глянуть на досуге.

Хотя мне для работы вполне хватает их родного софта VantagePoint. Хотя по большому счету магелланам внешний софт особо не нужен - его к компу подключил, он вилится как флешка обычная, просто копируйешь что надо куда надо.

Работа с картой - OkMap. Все карты у меня сейчас уже в GeoTiff переведены. Для создания атласов RMP есть утилитка RMPCreator.

[VPom]

Lev G. писал(а) Tue, 04 December 2012 14:37

Постараюсь выразиться точнее. Потеря сигнала всегда вызывает завершение секции в треке!

В вашем конкретном случае - да. В общем случае - нет. Так что ваша программа годится для обработки ваших треков. Но не других.

[Lev G.]

VPom писал(а) Tue, 04 December 2012 12:41

Lev G. писал(а) Tue, 04 December 2012 14:37

Постараюсь выразиться точнее. Потеря сигнала всегда вызывает завершение секции в треке!

В вашем конкретном случае - да. В общем случае - нет. Так что ваша программа годится для обработки ваших треков. Но не других.

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

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

Я не обещаю 100% гарантии поиска всех вылетевших точек(тут имеем дело с вероятностями) особенно когда 20% точек трека скачут на 1км как в вашем примере, но максимально увеличит вероятность нахождения таких точек задача которая должна быть нам по силам.

Что касается вашего предложения возвращать вылетевшие точки "туда где они должны быть", считаю это неправильным подходом, и вот почему. В данные трека не попадает информации о точности определения координат для каждой конкретной точки трека. Без таких данных мы не можем аппроксимировать данную точку иначе как поставив ее тупо посередине между двумя соседними точками, признанными верными. Но в этом же нет никакого смысла.

Или, быть может, ваши заказчики требуют чтобы трек после обработки содержал такое же количество точек как и до нее?