Комментарии 24
>> (previous_sample.course — sample->course)*(previous_sample.course — sample->course) >= COURSE_LIMIT*COURSE_LIMIT)
А как оно обрабатывает переход через 360 градусов?
И положите исходники на гитхаб, что ли.
А как оно обрабатывает переход через 360 градусов?
И положите исходники на гитхаб, что ли.
Посмотрел исходник из аттача.
Скажите, а зачем там переход в UTM вообще? Расстояния куда лучше считать напрямую из градусов координат.
Скажите, а зачем там переход в UTM вообще? Расстояния куда лучше считать напрямую из градусов координат.
Komzpa, спасибо за интерес к теме.
Во-первых, мы ведём расчёт по расстоянию между двумя позициями. Единственный корректный способ, как мы видим — это переход в метрическую систему на плоскости. В дальнейшем, при настройке трекера проще всего задать метры.
Во-вторых, зависимость расстояния межу объектами и координатами этих объектов очень сильно меняется от широты, т.е. используя ваш подход, вы можете ограничиться только одной, выбранной, областью.
В-третьих, если вы предлагаете ограничиться телесным углом, то проекция его на плоскость образует прямоугольную область, а нас интересует окружность.
Подход, который вы предлагаете, мы использовали в самом начале, но потом от него отказались. Если у вас есть более простое рабочее решение — предлагайте. Мы уверены, что читателям этой статьи будет интересно его увидеть.
Скажите, а зачем там переход в UTM вообще? Расстояния куда лучше считать напрямую из градусов координат.
Во-первых, мы ведём расчёт по расстоянию между двумя позициями. Единственный корректный способ, как мы видим — это переход в метрическую систему на плоскости. В дальнейшем, при настройке трекера проще всего задать метры.
Во-вторых, зависимость расстояния межу объектами и координатами этих объектов очень сильно меняется от широты, т.е. используя ваш подход, вы можете ограничиться только одной, выбранной, областью.
В-третьих, если вы предлагаете ограничиться телесным углом, то проекция его на плоскость образует прямоугольную область, а нас интересует окружность.
Подход, который вы предлагаете, мы использовали в самом начале, но потом от него отказались. Если у вас есть более простое рабочее решение — предлагайте. Мы уверены, что читателям этой статьи будет интересно его увидеть.
1) расстояние между двумя позициями на сфере считается напрямую, gis-lab.info/qa/great-circles.html — переход в UTM создаёт проблемы с масштабом на краю зоны, и зачем-то ограничивает область применимости вашего устройства.
2) сильно меняется — это по косинусу. cos(lat) и cos^2(lat) — множители, которые позволяют корректно считать расстояния/площади для небольших изменений по широте. Между двумя измерениями GPS-трекера широта меняется незначительно, если только вы не делаете что-то из аэрокосмической области — но тогда у вас и чипы будут другими.
Заходите по четвергам в минский хакерспейс на день открытых дверей, порисуем на доске.
2) сильно меняется — это по косинусу. cos(lat) и cos^2(lat) — множители, которые позволяют корректно считать расстояния/площади для небольших изменений по широте. Между двумя измерениями GPS-трекера широта меняется незначительно, если только вы не делаете что-то из аэрокосмической области — но тогда у вас и чипы будут другими.
Заходите по четвергам в минский хакерспейс на день открытых дверей, порисуем на доске.
Вообще, тема не раскрыта.
Топик называется «Алгоритмы устранения ложных и избыточных данных в GPS-потоке», а рассказано только про избыточные данные.
Как фильтровать «узелки» на стоянках?
Топик называется «Алгоритмы устранения ложных и избыточных данных в GPS-потоке», а рассказано только про избыточные данные.
Как фильтровать «узелки» на стоянках?
Это совсем не сложная задача. В ats24.ru мы решили ее на примитивном уровне — перемещение, относительно нескольких предыдущих координат < диаметра погрешности gps-модуля. Это если совсем упрощенно.
Да понятно, что Дуглас-пойкером давить — тоже вариант. Но у меня есть кучка треков, на которых узелки так не давятся :)
Есть способ, он не универсален, но неплохие результаты дает, если его правильно настроить.
Вокруг трека строится буфер, далее по области, покрытой буфером, пробегаем скользящим окном с радиусом, который несколько больше радиуса буфера (этот параметр подлежит подбору). Помечаем области, где окно попало внутрь буфера целиком. А дальше просто удаляем то, что попало в те области, где окно уместилось в буфер. Оно, конечно, может выкинуть и области честных петель трека, но если подойти к задаче творчески — можно свести это к минимуму.
А так, если пишете треки для OSM и т.п., запаситесь нормальным приемником, который не собирает мусор много ниже уровня шумов и не рисует фантазии, а для полного счастья — еще и акселерометром. Тогда уж точно с фильтрацией проблем не будет.
Вокруг трека строится буфер, далее по области, покрытой буфером, пробегаем скользящим окном с радиусом, который несколько больше радиуса буфера (этот параметр подлежит подбору). Помечаем области, где окно попало внутрь буфера целиком. А дальше просто удаляем то, что попало в те области, где окно уместилось в буфер. Оно, конечно, может выкинуть и области честных петель трека, но если подойти к задаче творчески — можно свести это к минимуму.
А так, если пишете треки для OSM и т.п., запаситесь нормальным приемником, который не собирает мусор много ниже уровня шумов и не рисует фантазии, а для полного счастья — еще и акселерометром. Тогда уж точно с фильтрацией проблем не будет.
Как фильтровать «узелки» на стоянках?
Действительно, тема устранения не раскрыта.
Мы перепробовали разные способы устранения узелков и остановились на использовании акселерометра. В нём использовался режим установки сигнала при превышении порога внешнего воздействия (т. е. когда транспортное средство начинает движение). Параметр был подобран экспериментально. Этот сигнал переводил прибор из режима покоя в режим движения.
Всё классно, если вы работаете с проверенным знакомым прибором и можете доверять его данным.
На практике китай-трекеры(а равно и отечественные говнотахографы) могут не то, что HDOP не передавать(это вообще редкость), но и врать насчёт кол-ва спутников/курса/скорости, передавать данные в чёрт-пойми каком порядке и т.п.
На практике китай-трекеры(а равно и отечественные говнотахографы) могут не то, что HDOP не передавать(это вообще редкость), но и врать насчёт кол-ва спутников/курса/скорости, передавать данные в чёрт-пойми каком порядке и т.п.
Странно, что такие оптимизации до сих пор имеют место в современной электронике.
А если данные сжимать, — сколько экономии будет? Или они и без этого уже сжимаются при передаче?
А что, если детальные данные хранить и сбрасывать только тогда, когда машина в зоне действия предустановленных или бесплатных wifi?
Что-то вспомнилась система мониторов в Киевском метрополитене: поезда по линиям катались с текущим контентом и обновляли базу данных, когда подключались к wifi в депо.
А если данные сжимать, — сколько экономии будет? Или они и без этого уже сжимаются при передаче?
А что, если детальные данные хранить и сбрасывать только тогда, когда машина в зоне действия предустановленных или бесплатных wifi?
Что-то вспомнилась система мониторов в Киевском метрополитене: поезда по линиям катались с текущим контентом и обновляли базу данных, когда подключались к wifi в депо.
miha2, данные сжимать можно, но сомнительна реальная выгода от этого, ведь это усложняет и протокол, и позиционирование прибора в псевдореальном времени (имеет смысл сжимать пакет данных, а не отдельные сэмплы), ну и сложность разработки не нужно исключать.
А насчёт накопления: представьте себе маршрут, который занимает не один, а несколько дней (международные перевозки). В этом случае накладываются серьёзные ограничения на общий объём хранимых данных. Но такие схемы, как вы упомянули, тоже используются. Всё зависит от конкретных задач.
А насчёт накопления: представьте себе маршрут, который занимает не один, а несколько дней (международные перевозки). В этом случае накладываются серьёзные ограничения на общий объём хранимых данных. Но такие схемы, как вы упомянули, тоже используются. Всё зависит от конкретных задач.
Плохо, что ваш алгоритм «срезает угол». Это, как раз, и есть потеря важной информации.
Тоже сразу обратил на это внимание. А также на каляки-маляки на правом верхнем углу, которые, очевидно, избыточны для этой картинки и которые срезаются элементарным прореживаем/слиянием ближайших точек (у меня скрипт на питоне написанный на коленке удалял подобные звёздочки-артефакты).
barker, если вы обратите внимание на самую первую блок-схему, то увидите ещё два этапа «Стабилизация» и «Фильтрация». В рамках этих этапов мы можете произвести усреднение, слияние и т. д. И только после этого мы переходим к анализу и избавлению от избыточных точек. То, что вы видите на картинке, это «сырые» NMEA-данные, полученные с GPS-приёмника без всяческой предобработки.
aryeh, всё определяется теми настройками, которые вы делаете. Можно увеличить чувствительность на смену курса и получится более приятная для глаз картина.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Алгоритмы устранения ложных и избыточных данных в GPS-потоке