Комментарии 6
XIII район Будапешта — ооочень густо застроенная местность, покрытие GPS неравномерное. Хороший результат для таких условий!
Тут стоит упомянуть, что за API Mapbox стоит опенсорсный движок OSRM, в котором можно в конфигурации выключить ограничение в 100 точек, если не полениться развернуть его на своём сервере.
Кстати, год назад ваш подход бы совсем не работал — изменение, которое позволяет передавать в OSRM трек одиночный, в котором есть неравномерные провалы во времени (а у вас они есть, вы ведь используете двумерное упрощение Дугласа-Пойкера вместо фильтрации), закоммитил хабраюзер Gard github.com/Project-OSRM/osrm-backend/pull/3815
С погрешностью всё довольно просто — она внутри преобразуется в радиус поиска дороги-кандидата, больше значение gps_precision — медленнее обработка, но более разнообразные варианты могут быть восстановлены. В коде радиус просто множится на три, и если этого значения нет совсем, его можно прикинуть по карте — взять типичное расстояние между двумя параллельными дорогами в вашей местности и поделить его на три. Ребята из lyft нашли регрессией более оптимальную формулу для нахождения радиуса, по своим данным — github.com/Project-OSRM/osrm-backend/pull/3184 — но оказалось, что с такой формулой перестаёт работать мапматчинг у тех, кто не озаботился передачей настоящего значения accuracy и придумывает его сам, как у вас.
Так и живём.
Кстати, год назад ваш подход бы совсем не работал — изменение, которое позволяет передавать в OSRM трек одиночный, в котором есть неравномерные провалы во времени (а у вас они есть, вы ведь используете двумерное упрощение Дугласа-Пойкера вместо фильтрации), закоммитил хабраюзер Gard github.com/Project-OSRM/osrm-backend/pull/3815
С погрешностью всё довольно просто — она внутри преобразуется в радиус поиска дороги-кандидата, больше значение gps_precision — медленнее обработка, но более разнообразные варианты могут быть восстановлены. В коде радиус просто множится на три, и если этого значения нет совсем, его можно прикинуть по карте — взять типичное расстояние между двумя параллельными дорогами в вашей местности и поделить его на три. Ребята из lyft нашли регрессией более оптимальную формулу для нахождения радиуса, по своим данным — github.com/Project-OSRM/osrm-backend/pull/3184 — но оказалось, что с такой формулой перестаёт работать мапматчинг у тех, кто не озаботился передачей настоящего значения accuracy и придумывает его сам, как у вас.
Так и живём.
Привет. Действительно на версии 4 и меньше прогон данных через Rpd мог ухудшить результат, мы в тот момент добавляли точки на полученные отрезки для создания равномерных данных.
С выбором точности все сильно упрощается, когда есть DOP или HDOP плюс информация о модуле GPS(какой именно установлен модуль) достаточно для определения радиуса поиска.
По поводу 100 точек все сложно, Mapbox отказывается снимать ограничение, а свои сервера для этих задач держать нам не то чтобы выгодно.
С выбором точности все сильно упрощается, когда есть DOP или HDOP плюс информация о модуле GPS(какой именно установлен модуль) достаточно для определения радиуса поиска.
По поводу 100 точек все сложно, Mapbox отказывается снимать ограничение, а свои сервера для этих задач держать нам не то чтобы выгодно.
DOP уже достаточно давно неактуален как значение, android и ios склонили рынок к тому, что теперь сами чипы прямо в NMEA-потоке репортят accuracy именно в том виде, в котором ожидает OSRM — как минимум на подопытном MTK в составе ZTE мы это наблюдали.
Решали ли вы, и решили ли, проблему систематической погрешности в gps, когда приёмник репортит координаты с отличной относительной, но ужасной абсолютной погрешностью? У нас в данных довольно частая история — трек идеально повторяет контуры дороги, но в пятистах метрах от неё, за пределами всех радиусов для мап-матчинга.
А вы живёте на Free Tier в Mapbox, или у вас почти нет трафика? Для коммерческих клиентов они не стесняются делать кастомные решения.
Решали ли вы, и решили ли, проблему систематической погрешности в gps, когда приёмник репортит координаты с отличной относительной, но ужасной абсолютной погрешностью? У нас в данных довольно частая история — трек идеально повторяет контуры дороги, но в пятистах метрах от неё, за пределами всех радиусов для мап-матчинга.
А вы живёте на Free Tier в Mapbox, или у вас почти нет трафика? Для коммерческих клиентов они не стесняются делать кастомные решения.
DOP уже достаточно давно неактуален как значение, android и ios склонили рынок к тому, что теперь сами чипы прямо в NMEA-потоке репортят accuracy именно в том виде, в котором ожидает OSRM — как минимум на подопытном MTK в составе ZTE мы это наблюдали.
У нас координаты берутся не с телефона, а блочка(донгла), который вставляется в автомобиль, есть устройства, которые уже несколько лет установлены, соответсвено прошивка модема в них не позволяет достать подобные данные.
Решали ли вы, и решили ли, проблему систематической погрешности в gps, когда приёмник репортит координаты с отличной относительной, но ужасной абсолютной погрешностью? У нас в данных довольно частая история — трек идеально повторяет контуры дороги, но в пятистах метрах от неё, за пределами всех радиусов для мап-матчинга.
Мы подобную проблему пока не решали. У нас достаточно интересная специфика GPS-треков. Большенство из них короткие(100-500 точек, точка +- раз в 3 сек), плюс после маршрута GPS выключается(экономия энергии), т.е. 1 маршрут обычнро проходит на одной пачке спутников и поиск происходит в начале поездки. Погрешностей как у вас в 500 метров мы не наблюдаем, максимум несколько метров.
А вы живёте на Free Tier в Mapbox, или у вас почти нет трафика? Для коммерческих клиентов они не стесняются делать кастомные решения.
У нас с ними контракт и большое количество запросов, почему они уперлись в 100 точек, я не знаю.
Погрешность GPS сенсора определяется погрешностью самого датчика и такими факторами как: ландшафт, скорость движения, количество и положение спутников.
Ну если лень почитать даже википедию, то придется объяснять на уровне детского сада. И так, погрешности делятся на шумовые и систематику. Шумовые — это те самые случайные погрешности, которые вы фильтруете.
Систематики — фильтруются иначе. Особенности систематики в том, что они одинаково смещают результата для группы последовательных решений. Систематики бывают самые разные и с самыми разными особенностями. Например, при переходе к новым эфемеридам систематика эфемерид глонасс максимальна, потом 15 минут она снижается и 15 минут нарастает. В момент смены эфемерид глонасс может возникнуть скачок координат.
Систематика эфемерид GPS иная — скачок в момент смены эфемерид и нарастающая в течении 2 часов систематика.
Ну и так далее и так далее…
А вывод прост. После вычищения шума стоит выделить соседние точки, проанализировать
систематическое смещение куска и свинуть точки с его учетом. При этом короткая систематика (менее 15 минут) всего одна — многолучевой прием. Все остальные систематики длинные.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Map matching и обработка сырых данных GPS в промышленных масштабах