Я работаю программистом в компании Автолокатор, которая предоставляет услуги мониторинга автотранспорта организациям и частным лицам.
Мною достигнута договоренность с руководством о возможности предоставления данных для сообщества OpenStreetMap. Предлагаю обсудить в каком виде эти данные удобнее всего можно использовать. Кроме поднятия GeoServer пока ни чего не придумал.
Вероятно потребуется некоторая фильтрация данных: например некоторые блоки присылают свои координаты раз в несколько часов и соединять линиями такие точки точно не следует.
Я бы не отказался от треков в дали от магистралей. А то как начнёшь рисовать районы в области так полтора трека на сотни квадратных километров. Естественно никаких автозаливов, готов их перебрать вручную.
Было бы неплохо ещё извлекать покрытие, вдруг вы там видео с регистраторов собираете
Потому что линия с интервалом записи раз в час будет там скорее мешать, чем помогать. Плюс ко всему эти треки скорее всего и так идут по федеральным трассам, где покрытие уже хорошее. Сливать надо только экзотику и хорошо прорисованную, нечего базу захламлять.
Точки, кстати, интересная идея, там где надо и так получится линия.
GeoServer как раз позволяет отдавать WMS данные, которые прикручиваются в качестве слоя, например в JOSM.
Не совсем, https://api.openstreetmap.org/api/0.6/trackpoints возвращает нормальный трек, где загруженные в проект треки идут в виде сегментов. Поэтому у точки есть вся мета-информация, чья она, кто следующая, а значит направление и скорость.
FTP с треками, порезанными по регионам и районам (admin_level=6) - вполне пригодный к использованию вариант. Захотел порисовать нужный район - скачал папку с треками этого района (при необходимости, отфильтровав нужное силами файлового менеджера по дате), открыл в JOSM и вперёд. Там, где границ районов в ОСМе нет, можно порезать регион по градусной сетке.
Исключение неинтересных треков сделать довольно просто, нужно взять из ОСМа все highway выше tertiary (как вариант - вообще все highway) и ещё до выкладывания треков на ftp вычищать из них все точки, которые ближе 50 м (это значение стоит уточнить, возможно лучше иное число) от существующих в ОСМе дорог.
Для начала подхода выше, по моему мнению, вполне достаточно. Вторым этапом уже можно подумать о реализации предотвращения выкладывания множества треков по одной и той же дороге (иметь штук 5 треков по одной и той же дороге за год - вполне ОК, а после этого дубли будут только мешаться). Тоже вполне можно автоматизировать такое.
Третьим этапом уже можно предусмотреть несколько наборов треков:
а) треки по уже существующим в ОСМе дорогам, без дублей - для уточнения имеющегося
б) треки по несуществующим в ОСМе дорогам, без дублей треков по одном и тем же местам - для их добавления
в) треки без фильтрации и без исключения дублей - для желающих пофильтровать и поанализировать по своим хитрым алгоритмам.
г) можно подумать ещё о других подходах автоматической классификации треков.
А почему именно FTP, чем WMS-подложка не удобна? Если резать на треки, то как, один автомобиль - один трек? А если там 500 машин проехало?
Зачем разбивка по дате? Если включить в JOSM слой с загруженными на сервер треками там такого нет.
Опять же можно такие типы треков разнести по разным слоям, чтобы удобно переключаться, а не ковыряться с кучей файлов / папок на FTP.
FTP предложил исключительно из-за простоты реализации, можно и WMS.
Да, один автомобиль - один трек. Если 500 автомобилей проехало, оставлять на основном слое только треков штук 5 (желательно ещё половину в одном направлении, половину в другом, но для начала можно не учитывать направление)
Разбивка по дате нужна для того, чтобы отфильтровывать устаревшие треки. То, что такого нет в JOSM - заметная недоработка там.
Если в имени файла на FTP (или подобном хранилище) заложить bbox трека, то можно будет наладить фильтрацию по координатам при скачивании.
3 знаков после запятой достаточно для точности около 100 метров, конструкт получается например такой: 55754_37620_55981_37254
Данные изначально лежат в простом виде в базе ms-sql.
Для geoserver они перекладываются postgresql + postgis. Таблицы называются соответственно points и lines.
3 ) Для прекладывания используется написанное мною приложение на C++ (с использованием SOCI).
Текущий алгоритм перекладывания данных:
Извлекаем из ms-sql (пока по одному автомобилю) записи отсортированные по времени: id авто, время, широта, долгота.
Убираем дубликаты точек по широте и долготе (стоянка).
Пишем в points каждую точку в отдельности, в lines линию целиком.
Сохраняем в отдельную таблицу дату последней точки и id авто, чтобы в следующий раз начать работу с этого времени.
Посмотреть слои в браузере можно пройдя по ссылкам: pointslines.
С points более менее все хорошо, про lines напишу ниже.