Имеется база треков одного из автопредприятий, занимающегося грузоперевозками.
Сделал конвертер, который преобразовал треки в gpx формат. Получилось около 1300 треков, покрывающих несколько областей.
За качество данных отвечаю. Всю обработку делал на своей стороне, т.е. почистил треки от разлетов на стоянке, случайных точек и т.д. Т.е. имею чистые треки с временными метками. Все треки проверены.
Теперь вопрос, как правильно загрузить эти данные в осм. Треки разбиты по поездкам каждой машины за каждый день. Теоретически могу объединить все в один или несколько gpx файлов (подскажите чем лучше слить треки). Но объем слитых файлов будет немаленький (общий размер всех gpx 150 мб).
Если загружать по одному, я за…юсь 1300 треков вводить. Как правильно поступить в данной ситуации? Может есть какой загрузчик пакетов, но будет ли идеологически верно столько треков за раз грузить.
P.S. Против публикации данных возражений нет, по этим трекам сотрудники предприятия отрисуют все недостающие дороги (инструктаж по пользованию джосмом провел 
), чтобы потом строить по ним маршруты.
На osm.org загрузка треков возможна в зип-архиве.
Вот архивировать зипом эти разбиения и через osm.org грузить. Можно заархивировать по областям.
Ага, спасибо, вижу что есть такая возможность. А идеологически это нормально столько треков за раз грузить?
Как их разбить по областям я даже хз, у меня mysql база вида: lat/lon/alt/speed/time . Машины катались между областями, поэтому большинство треков затрагивают несколько областей/районов.
Очень много не лейте за раз - это нагрузка на сервак. А так - 200 треков по 30-40 км он кушает влет.
Еще вопрос, не повлияет ли такое количество треков на удобство отрисовки этих регионов. Т.е. если я буду грузить потом данные осм с данными треков, не скажется ли это на быстродействии и не сделаю ли я медвежью услугу тем кто будет также этот регион обрисовывать.
Просто , если я гружу все треки в josm , он начинает аццки тормозить. Хотя сетка дорог получается просто презамечательная и накатанная по многу раз. Отрисовывать и править по таким одно удовольствие.
Я брал месячный интервал, многие из маршрутов понятно повторяются, но исключить повторы нет ни какой возможности.
Лейте, раз треки хорошие. Никто же не грузить целую область разом…
А подскажите пожалуйста, по какой формуле рассчитать пройденный путь в метрах между 2-я точками lat1/lng1 - lat2/lng2 , хочу еще немного почистить треки от ошибочных точек.
Готовое решение
https://developers.google.com/maps/documentation/javascript/reference?hl=ru#spherical
Алгоритм
http://stackoverflow.com/questions/27928/how-do-i-calculate-distance-between-two-latitude-longitude-points
Через некоторое время возникла другая проблема. Опять-таки имеем треки, по которым примерно полгода ежедневно катались более 100 машинок по Украине . Все треки качественные, однако их около 13 тыс штук, и они большей частью перекрывают друг друга (ибо развозки часто идут по одинаковым маршрутам).
Если я их все выгружу, в некоторых местах прогрузка треков будет конкретно так подвисать.
Как выход вижу какой-то софт или скрипт ,который позволит наложить треки друг на друга и получить в результате сводный , который уже можно залить на сервер.
Если бы кто-то помог мне в данном вопросе, был бы очень признателен.
Сводный трек делать и муторно, и немного опасно для базы - где-нибудь да неправда будет при таком количестве. Лучше как-то вручную или программно сделать выборку нескольких сотен приличных треков. Или (если регион небольшой) - отрендерить всё в тайлы и положить на какой-нибудь сервер.
Регион Северо-Восток Украины. 
Несколько крупных областей. По каким критериям отбирать треки ума не приложу.
Попробовать загрузить все к себе в JOSM, пытаться еще в ручную зачистить и потом все таки объединить хотя бы в несколько треков. Но что-то мне кажется , что на таком кол-ве одновременных треков josm на моем i7 2600 сдуется.
Если у вас нет сохраненных значений HDOP, (оценочной ошибки) задача довольно заметно усложняется, потому что откровенный мусор выбросить мы уже не можем.
В любом случае, работать стоит с треками, которые порезаны на куски по расстоянию (с этим легко справляется gpsbabel), тогда в каждом конкретном месте треков будет больше, но точек, которые принадлежат им, будет меньше.
Дабы не работать с местами, где треков заведомо мало, стоило бы построить карту максимальных плотностей точек для окна в десятки метров. Тогда можно было бы сразу исключить территории, где треков и так не много. Сделать такую оценочную схему можно просто - перепроецировать координаты точек в любую прямоугольную систему координат (Меркатор на сфере, например) и округлить координаты до сетки в 50 метров (поделить нацело на 50 и умножить результат обратно). А потом подсчитать число точек в каждом узле сетки - где их будут единицы десятков и менее - там прореживать треки не нужно, там где сотни и более - очевидно, нужно.
Алгоритмически задача фильтрации треков сложна и требует достаточно творческого подхода.
Плохо что в итоге получится не направленная линия из точек а змейка. А вообще можете их выложит в паблик ?
Раз такая возможность усреднить есть, лучше это сделать. Это даже нужно сделать, в целях повышения точности (т.к. единичные треки приемлимой точности не дают - нужно проехаться всё-таки несколько раз).
Ну или тогда загружать всё, что есть. Что-то выкидывать случайным образом не есть хорошо.
Идея с HDOP разумна. Я так понимаю, у автора есть исходные данные, раз конвертер в gpx писал сам?
Есть исходные данные 2 таблицы:
в одной список треков , во второй список точек, входящих в трек
logtitude/latitiude/altitude/heading/ground_speed/timestamp
На треки делит сама программа, не совсем понимаю как точно, но скорее всего на основании какого-то таймаута стоянки.
на основании этих данных выгребаю данные и формирую файлы kml/osx , где каждый файл это один трек (одна поездка) выбрасывая лишие точки со стоянки (на основе расстояний между предыдущей и следующей точками)
Пример треков:
http://ge.tt/9qreOcX/v/0?c
По всем трекам в последствии будут отрисованы дороги (осм используется на предприятии для логистики).
А можно ли как-то на основе имеющихся данных рассчитать HDOP ? По сути скрипт экспорта я писал, поэтому можно будет сделать корректировку.
Если “heading”<>“HDOP”, то нет. HDOP - это горизонтальная точность измерения координаты. Может быть расчитана и записана только тем аппаратом, который проводит измерения.
heading - скорее всего, направление (курс).
HDOP - это параметр, который вычисляет приемник на основании условий приема. В базу он, очевидно, не попадает (это ведь диспетчерская система, так что там такие детали не нужны никому). Посчитать его заново - невозможно (точнее - теоретически его можно было бы прикинуть, но для этого нужна информация, которой тоже нет - номера спутников, которые использовались в определении координат конкретной точки, а тут даже числа спутников нет).
Усреднение, конечно, что-то дает, хотя это смотря как его сделать. В идеале нужно выделять сегменты с постоянным в некоторых пределах вектором скорости (чтобы не усреднить треки по разным направлениям и не рассматривать выбросы любой природы, типа единичных заездов во двор) и т.п., а то жуть будет.
Я бы нача с того, что по этим секторам, что Вы там предлагаете проверил наличие в тех местах треков уже загруженных в ОСМ. Потому, что из примера я вижу, что 80% можно и не грузить, оно и так есть.