Свежие треки вместо старых

Всем привет. Меня волнует вопрос, нужно ли выкладывать записанные треки, если они проходят по местам с плотным трекопокрытием? Верны ли следующие мои рассуждения?

Аргумент против: на крупных дорогах, где много треков, загрузка слоя треков в редактор утяжеляется, а за треками не видно дороги вместе с прилегающими объектами (обочинами, отбойниками), отчего привязка смещения к трекам только усложняется.

Аргумент за: может, каким-то сервисам по отслеживанию скоростного режима/пропускной способности дорог важны свежие данные о скоростях?

Есть ли в самой базе треков OSM механизм отсеивания треков “за неактуальностью” помимо удаления трека самим пользователем? В частности, редактор ID показывает все треки или “последние N”?

До сих пор я вырезал куски треков в областях с малым покрытием, остальное выкидывал. Может, не стоит этим заниматься?

механизм фильтрации треков к JOSM прикрутить можно, нужно только написать правильный плагин или через внешний скрипт прогоноять.

по базе треков тоит прогнать скрипт вырезания “розочек стояния” вот те реально моск выносят, но кто этим будет заниматься…

Единственный минус я вижу только в кляксах, потому что нет механизма их убрать из базы. В остальном же польза есть. Вырезать конечно можно, но мне кажется это лишним телодвижением. JOSM вполне позволяет отфильтровать треки по дате.

Если треки свежие и хорошего качества, то да

В JOSM, например, можно настроить слой треков: цвет, прозрачность, убрать линии (оставить только точки).

Насколько я знаю, на данный момент информация о скоростях никак не используется

Про базу не скажу, но JOSM умеет фильтровать по дате (хотя скачивает все равно полностью)

в АПИ выносить функции вырезания треков бессмысленно. так что единственный вариант напрямую корежить базу треков.

Стоит заливать абсолютно все треки, независимо от плотности покрытия. Желательно заливать в режиме Identifiable или хотя бы trackable.

Аргументы:

  1. Чем больше данных тем лучше статистический анализ, напрмер для оценки средней скорости или точности привязки снимка
  2. Большая часть треков в базе это бесполезный private хлам. Без таймстемпов по ним невозможно даже не отличить, записан трек автомобилем на дороге, велосипедом на обочине или пешеходом на тротуаре.
  3. Треки устаревают, если где-то можно было проехать 10 лет назад, не факт что сейчас там не поставили забор.

Нет, но в JOSM есть фильтры, в том числе и по дате.

вспомнил еще один момент устаревания треков.
http://openstreetmap.ru/#map=17/55.91271/48.36637&layer=SG
Когда-то развязка была в виде длинного овала, как на треках. Потом ее переделали в кольцо, как собственно в осм. Вот тут реально стоит вырезать треки старого варианта проезда.

Я вот в этом месте летом проезжал. Мой трек спрямленный, старые треки ехали по дуге. Я несколько раз пересмотрел на всех картах, на гугл панорамах и не мог понять как это. В итоге нашел запись с регистратора - там построили спрямление.
http://openstreetmap.ru/#map=16/49.8293/33.1974&layer=SG

algot, в соседней теме BushmanK подсказал - можно в НЯКе подглядеть. У них треков на порядки больше…

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

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

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