Из этого он должен планировать время прибытия. А маршрут строить с учётом в первую очередь исходя из key:highway, maxspeed:practical, key:smoothness, key:surface:grade и т. п.
Как maxspeed:practical может толкать на противоправные действия? Тем, что программа не поведёт по колдобинам, когда есть отличная дорога? Если рендеру нужно, он сам “подрежет” maxspeed:practical под не более maxspeed, а база OSM должна отображать реальность. И, кстати, двигаться со скоростью, значительно меньшей, чем скорость потока - опасно.
И зря я обозвал давеча maxspeed:practical “костылём”, это скорость “ребра” в чистом виде, важнейшая информация для роутинга. В вики ИМХО надо написать, что тег - только для роутинга, и если кто не знает зачем и как, пусть его не трогает.
Очень тонкое использование maxspeed:practical вместо smoothness ? То есть, если maxspeed:practical шибко больше maxspeed, то smoothness явно хороший, даже если мы реально там будем планировать maxspeed, то инфа из maxspeed:practical не пропадет.
Ну это, как мне кажется, в большой степени ловля блох.
Всё-таки для многих главный критерий — время проезда.
Нет, важно. Одно дело “ползти” за фурой по хорошей дороге, а другое — трястись на ухабах. Поэтому я считаю логичным на разбитых дорогах ставить maxspeed:practical ориентируясь на берегущего машину и пассажиров водителя, осторожно переваливающегося из ямы в яму.
Во общем, предложение такое. Использование тега как “практическая максимальная скорость” совершенно никому не нужно, “средняя скорость потока” - мало полезно. Давайте продолжать использовать его только для правильной маршрутизации.
Спорно. Я езжу по плохим дорогам по принципу “больше скорость - меньше ям”, но с радостью объеду этот участок, пусть и в три раза дальше. И поеду даже медленнее, соблюдая ПДД и наслаждаясь движением по ровному шоссе.
Вы никогда не пробовали добиться абсолютно идеального роутинга в отдельно взятом городке, что бы СитиГид (например) из любой точки в любую вёл так, как поехал бы местный? Для решения задачи одобнее ставить сразу цифры, а не “колдовать” с сочетаниями smoothness, surface:grade и т. п.
В покетгис есть простая настройка: 5 градаций между Быстрее и Короче.
Так я подозреваю, что самый массовый выбор это пара самых быстрых случаев.
Можно придумать другие — дело нафигатора. А вот адекватные данные для реализации минимизируемой функции (время или расстояние или их смесь или количество ударов по задницех на кочках) вполне можно и должно расставлять в ОСМ.
Это типичное предложение “рисовать под рендер”.
Если использовать некий тег не в качестве объективной физической величины, в качестве костыля для конкретной (несовершенной) программы, сразу возникает вопрос - под какую конкретно программу мы “рихтуем” данные OSM?
под Навител навигатор?
под Гармин?
под 7 дорог?
под Ситигид?
под iGO?
…
Использовать некий тег как абстрактный настроечный параметр, совершенно невозможно будет сделать единообразные правила его применения и использования.
Поэтому вывод может быть только один: тег должен отображать объективную физическую величину, а смогут ли существующие навигаторы (совместно с конвертерами) использовать этот тег и, если смогут, как именно, - проблемы конкретных навигационных программ.
Если исходить из этого, то тег в виде maxspeed:practical совершенно неприемлем.
Может быть только maxspeed:citygid:practical, maxspeed:garmin:practical, maxspeed:igo:practical…
Да еще с многочисленными уточнениями, зависящими от настроек конкретной программы, потому как обычно в программах маршрутизации поддерживается несколько режимов прокладки маршрута.
Вот именно!
Более того, сама идея - добиться маршрута, как прокладывают местные - от несовершенной программы (например, не учитывающей пенальти от светофором или разницы в скорости прямого проезда перекрестка и того же перекрестка с поворотом - что требует кроме весов ребер введения весов узлов, причем, зависящих от траектории), совершенно дохлая.
А введение необъективных (подгоночных под несовершенный алгоритм) данных явно препятствует разработке более совершенных алгоритмов, который мог бы использовать объективные данные, которые пока не востребованы современными маршрутизаторами.
maxspeed:practical должен содержать именно время нормальной езды, а не некое значение некой целевой функции некоего навигатора
Просто конверторы и навигаторы ничего другого понимать не хотят, вот и получился один рычаг на все случаи жизни.
Напоминаю, что этот вопрос уже обсасывали (кому не лень, - найдите старую тему), и выяснили, что никто толком не понимает, что же такое maxspeed:practical. Основной вариант тогда был “комфортная скорость среднего авто, чтобы не сильно напрягать подвеску”
Тогда же для желающих тюнинговать маршруты в навигаторах придумали тег avgspeed - “средняя прогнозная скорость”.
Пока.
Пока, действительно, все имеющиеся в OSM варианты вынужденно впихиваются в единственное число, используемое навигатором. Но хочется верить, так будет не всегда.
И если мы хотим, чтобы это когда-то произошло, уже сейчас нужно позаботиться, чтобы в OSM к тому времени было несколько “рычагов”, которые мог бы использовать маршрутизатор, построенный по новым более совершенным алгоритмам.
Мне кажется, обсуждение пора переводить в конструктивное русло, способное привести, по меньшей мере, к созданиюв wiki странички RU:Key:maxspeed;practical с вполне конкретным и одобряемым более или менее всеми содержанием.
Для этого, мне кажется, нужно сделать 2 шага:
Убедить сомневающихся, что в OSM не место не имеющим физического смысла настроечным коэффициентам под конкретный режим работы конкретной программы, какими бы благими целями это ни прикрывалось.
Определиться с формулировкой физического смысла величины maxspeed;practical. На этот счет, как я понимаю, существует две основные точки зрения:
минимум из 3-х величин:
1. Ограничения по ПДД.
2. Ограничения по физическим характеристикам дороги (качество покрытия, извилдистость и пр.)
3. Ограничения, связанные с загруженностью дороги, пешеходами и пр.
минимум их 2-х величин (ограничения ПДД полностью игнорируются):
1. Ограничения по физическим характеристикам дороги (качество покрытия, извилдистость и пр.)
2. Ограничения, связанные с загруженностью дороги, пешеходами и пр.
Каждый из вариантов имеет свои плюсы и минусы, остановлюсь на таковых для второго варианта:
если значение maxspeed;practical > maxspeed, то оно просто может быть проигнорировано программами, которым нужен первый вариант.
значения не ограниченной посредством ПДД скорости весьма субъективны: с одной стороны, не так мало машин, максимальная скорость которых не превосходит 130 км/ч (например, внедорожники), а с другой - этот тег может превратиться в поле битвы людей, желающих чем-то померяться, например, максимальной скоростью своего автомобиля. Отсюда - неизбежная война правок.
В таком случае (напомню, что международным голосованием тег maxspeed:practical отклонен) следует ввести в русскоязычной части OSM оба предлагаемых тега с описанием в wiki и обязательными взаимными ссылками.
Любой новый тег на момент введения никем не поддерживается.
Если тег окажется полезным - его поддержка появится.
Нет. Это предложение ставить скорость ребра. А уже дело рендера, как эту информацию использовать. Если дорога А длиной 100 км, а дорога Б - 50, но ехать лучше по А, значит maxspeed:practical дороги А должно более чем в два раза превышать показатель дороги Б. Просто, понятно, удобно, полезно.
