Карта треков

Ilis · 2010-07-12T08:19:24.000Z

В статье в Википедии есть такая картинка:
http://upload.wikimedia.org/wikipedia/commons/8/83/Bedford_tracklogs_inverse.png

Интересно было бы посмотреть на весь мир Может уже есть, или кто-нибудь сможет сделать рендерер чистых треков?

AMDmi3 · 2010-07-12T13:46:38.000Z

А нигде нет аналога planet.osm, только с треками?

Aleksandr_Dezhin · 2010-07-12T13:59:00.000Z

AMDmi3:

А нигде нет аналога planet.osm, только с треками?

Нет, хотя очень хочется. Тогда и рендер и какая-то расширенная обработка треков будут возможны. Но я так понял, что скрывать треки - это политика партии.
Можно конечно многое из веб-интрефейса грабить, т.к. id последовательные, но это же не комильфо.

andriano · 2010-07-12T16:25:13.000Z

А в чем, собственно, проблема? В том, чтобы получить треки или в том, чтобы их визуализировать?

Кстати, раз уж зашла об этом речь - есть какая-либо документация по форматам треков, которые должны быть или желательны для OSM? А то у меня проблема с аппаратным навигаторм - только не знаю с чем: с карточкой памяти, с самим навигатором или с софтом, причем лицензионная политика Навител не дает возможности локализовать проблему. Отсюда и идея записывать треки самописной софтинкой.

Upliner · 2010-07-12T16:36:40.000Z

andriano:

А в чем, собственно, проблема? В том, чтобы получить треки или в том, чтобы их визуализировать?

Чтобы получить, разумеется.

andriano:

Кстати, раз уж зашла об этом речь - есть какая-либо документация по форматам треков, которые должны быть или желательны для OSM?

В OSM практически везде используется GPX

andriano · 2010-07-12T17:23:17.000Z

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

AMDmi3 · 2010-07-12T18:32:06.000Z

Aleksandr Dezhin:

Нет, хотя очень хочется. Тогда и рендер и какая-то расширенная обработка треков будут возможны. Но я так понял, что скрывать треки - это политика партии.
Можно конечно многое из веб-интрефейса грабить, т.к. id последовательные, но это же не комильфо.

А зачем последовательные? Хватило бы координат + timestamp для тех треков где это разрешено, т.е. ничего сверх того, что можно получить через API. При наличии timestamp’ов из точек и сам трек можно почти всегда восстановить. Просто хочется все точки одним большим куском.

Upliner · 2010-07-12T18:40:37.000Z

AMDmi3:

А зачем последовательные? Хватило бы координат + timestamp для тех треков где это разрешено, т.е. ничего сверх того, что можно получить через API.

Сколько-нибудь большую территорию так не выкачаешь, скорее всего забанят как osmget-чиков. А для маленькой территории JOSM-а вполне хватит для просмотра треков.

AMDmi3 · 2010-07-12T18:44:00.000Z

andriano:

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

Некоторые прореживают треки, но я лично считаю, что это совершенно не нужно. По густому треку с точками через 1 секунду легче понять, действительно ли дорога кривая, или просто трек “гуляет” из-за погрешности. Кроме того, прореженные данные быстро потонут среди других треков, что снижает их ценность. А вот вырезать из трека стояночные кляксы и просто кривые куски - это хорошо и правильно. Я для этого пользуюсь http://activityworkshop.net/software/prune/.

AMDmi3 · 2010-07-12T18:45:21.000Z

Upliner:

Сколько-нибудь большую территорию так не выкачаешь, скорее всего забанят как osmget-чиков. А для маленькой территории JOSM-а вполне хватит для просмотра треков.

Поэтому я и говорю, что хочется аналог planet.osm, но с треками.

andriano · 2010-07-13T04:04:26.000Z

AMDmi3:

Некоторые прореживают треки, но я лично считаю, что это совершенно не нужно. По густому треку с точками через 1 секунду легче понять, действительно ли дорога кривая, или просто трек “гуляет” из-за погрешности. Кроме того, прореженные данные быстро потонут среди других треков, что снижает их ценность. А вот вырезать из трека стояночные кляксы и просто кривые куски - это хорошо и правильно. Я для этого пользуюсь http://activityworkshop.net/software/prune/.

Вообще-то алгоритм прореживания, если уж его использовать, нужно настраивать так, чтобы не происходило потери информации. Т.е. как минимум, отслеживать производные и само прореживание производить с запаздыванием не менее 2 точек (т.е. принимать решение, выкидывать ли точку, только после того, как за ней поступило еще минимум две).
И еще: что значит “потонут”?

AMDmi3 · 2010-07-13T13:14:29.000Z

andriano:

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

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

andriano:

И еще: что значит “потонут”?

Значит не будут вносить в пакет треков вклад пропорциональный 1/N, как нужно для честного усереднения. В пограничном случае - когда есть два трека, прореженный и нет, рисовать будут по второму, даже если он менее точный, потому что редкие точки или обрывки рядом с цельной линией никак не воспринимаются.

andriano · 2010-07-13T15:24:12.000Z

AMDmi3:

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

Нет, неправильно. Это значит, на длинном прямом участке можно выкинуть все точки кроме 4-х: по 2 крайних с каждой стороны. Но, боюсь, такой трек, действительно “потонет”.

Значит не будут вносить в пакет треков вклад пропорциональный 1/N, как нужно для честного усереднения. В пограничном случае - когда есть два трека, прореженный и нет, рисовать будут по второму, даже если он менее точный, потому что редкие точки или обрывки рядом с цельной линией никак не воспринимаются.

Получается, целесообразно вырезать лишь стоянки, оставляя все остальное.

Кстати, есть ли ограничения на объем трека? Что лучше: писать один большой многочасовой трек или сбрасывать его по кусочкам из сотен или тысяч точек?

AMDmi3 · 2010-07-13T15:36:29.000Z

andriano:

Получается, целесообразно вырезать лишь стоянки, оставляя все остальное.

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

andriano:

Кстати, есть ли ограничения на объем трека? Что лучше: писать один большой многочасовой трек или сбрасывать его по кусочкам из сотен или тысяч точек?

Не припомню. Учитывая, что в загрузке треков написано, что они могут обрабатываться до нескольких часов, а пятичасовые поездки обрабатываются на деле не дольше минуты, я думаю в пределах нескольких суток ограничений нет, и если что, “оно напишет”, так что треки можно заливать как удобно самому себе. Я никогда ничего не бил, что за день наездил - почистил и залил. Один раз наоборот склеил дорогу в два конца - 47k точек, все нормально.