Правильно ли я понял, что Вы поддерживаете вариант “2”?
Правильно, давайте выпилим из базы все координаты!
Надеюсь, ни у кого нет сомнений в том, что координаты являются именно вычисленными величинами?
“Чистый” максимум, весьма вероятно, не будет удовлетворять условиям безопасности ни для подвески, ни для самого водителя.
А если брать в качестве “водораздела” некоторый процент (например, 85%), то треки пешеходов будут вносить свой вклад в статистику и искажать результат.
Опять же, бывают случаи, когда “пешком быстрее”. Поэтому теоретически скорость пешехода может попасть не только в “нижние 85%”, но и в “верхние 15%”, а это уже совсем другая погрешность.
Не от балды, а проверенный лично параметр. А если и от балды, то это проблема того, кто тег установил. Объективность же статистических данных пока не доказана. Имеются примеры длительних ремонтов дорог. Почти 2 года движение затруднено, а новых треков с гулькин нос. Видимо дедок проехал, 1% из 15% не вписывающихся в 85% адекватрных водителей, в скип этот трек, нормальная там скорость движения. Держите статистику подальше от базы ОСМ.
Зачем же в крайности впадать.
Автоматом по трекам ничего, ИМХО, не выйдет. Мотоциклисты, снегоходы, пассажиры ОТ…, слишком много нюансов.Например, по Рощино и окрестностям треки во многом отражают мои перемещения. В основном на велосипеде и на УАЗике, притом по весьма специфическим маршрутам, мало завязанным на маршрутизацию и часто с заниженной или завышенной скоростью.
Ну, тогда давайте не все, а через одного 
Вот именно!
В наших условиях ни вычисленное значение не имеет существенных преимуществ перед экспертной оценкой, ни экспертная оценка не имеет существенных преимуществ перед вычисленным значением.
На каких-то участках дорог лучше будет одно, а на каких-то - другое.
Предлагаю зафиксировать оба метода в качестве допустимых и равноправных при занесении в базу конкретных величин.
Добавлю очевидные дальнейшие последствия. К моменту окончания ремонта накопится медленных треков и чудо бот наконец сообразит о том, что не плохо было бы занизить maxspeed:practical, но вот незадача, к тому моменту maxspeed на этом участке будет уже на 50 а 70 без единого светофора, но бот по трекам укажет maxspeed:practical = 10, вот оно, чудо инженерной мысли. А местным маперам до этого места уже нет дела, ибо ремонт окончен, дорога открыта, изменения в ОСМ внесены.
И в том и в другом случае параметр должен задаваться со знанием местности, а не тупо лепится ботом по всем найденным трекам.
А пробковые сервисы-то и не знают, что нельзя полагаться на статистику 
.
Если создатель программы (алгоритма) навигации захочет использовать такие данные по трекам, то он сам (программа конвертации), без нашей помощи, вытащит эти данные из OSM, рассчитает как ему надо и вставит в программу.
Не надо никаких ботов, пусть его ручками расставят те кому это нужно и там где это понадобится.
С этим кто-то спорит?
Скажу больше: решение о том, какой из двух указанных способов применять - тоже экспертная оценка.
А значит, как ни крути, - приоритет у экспертной оценки.
Другое дело, что при наличии некоторой статистики перед экспертной нужно будет сделать целый ряд количественных оценок.
Например.
Пусть мы предполагаем maxspeed:practical=50.
Соседние возможные значения: 40 и 60.
Чтобы уверенно попадать в 50, погрешность оценки должна быть не хуже 20%.
Количество измерений, по которым проводится оценка, должно быть не менее 25.
Учитывая суточную цикличность и характерное время возникновения/рассасывания пробки в 30 минут, на сутки должно приходиться 25483=3600 измерений (3 - пикфактор).
Учитывая недельную цикличность и сезонную цикличность 360074~100 000.
Кстати, интересно, можно ли где скачать все имеющиеся в OSM треки по некоторой территории?
Ну, скажем, в пределах local.osm?
Так - для оценки возможности вычисления статистических характеристик.
Вы хоть приблизительно представляете объем работы?
Если сейчас конвертация занимает десятки минут, то Вы согласны будете, что данные OSM, которые берутся для конвертации, к моменту окончания работы конвертера устареют на несколько месяцев?
Кто мешает актуальную картографию и скоростные характеристики готовить отдельно? Если скоростные характеристики устареют на пару месяцев - думаю ничего особо страшного не случится.
Так никто и не против.
Вопрос только - где эти скоростные характеристики хранить: у себя под одеялом или в общей базе?
Для механической обработки треков OSM нужен свой тег или сервис, здесь это — кукушкино яйцо. Да и сильно я сомневаюсь, треки в OSM не те, что получают пробочные сервисы, это часто треки маперов, а не свободно перемещающихся масс транспорта.
Разве кто-то предлагает напустить бота-скоростемера?
Ну, вообще говоря, эта мысль витает в воздухе.
Перед этим, правда, неплохо бы в оффлайне проанализировать, что представляют собой эти треки, и можно ли надеяться извлечь из них какую-то пользу с точки зрения оценки распределения скоростей.
Поэтому повторю вопрос: знает ли кто способ получения всех имеющихся в OSM треков на определенной территории.