Ещё раз про maxspeed:practical

+10
Иначе у нас может появится access:practical - доступа нет, но если залез, то можно (GaM ©), все так ходят; restriction:practical - знак запрета поворота есть, но все так ездят и т. п.
Не при каких условиях информация из БД не должна толкать пользователя на противозаконные действия.

Забавно всё это, особенно про светофоры. Почему программа навигации не может поставить штраф за проезд перекрёстка со светофором, поворот налево и пр. Почему для этого нужно насиловать базу. Если программы навигации не могут - то liosha сможет, давайте сформулируем нашу просьбу, он никогда не отказывается воплотить реалистичные запросы.

Тег - не костыль. Это его используют убогие некоторые нав. программы и конверторы, а точнее их пользователи, в качестве костыля. Если везде значения будут адекватно расставлены, то это не будет костылем, а будет только польза.

Пора заполнять статистику по времени суток и дням недели. :slight_smile:
Давно собирался заняться, а тут вот нашел правильный тег
maxspeed:practical:conditional

maxspeed:practical=80
maxspeed:practical:conditional=120 @ (06:00-20:00):

Неверно понимаете. maxspeed:practical=90 в Питере — часто полная утопия. По трамвайным путям прыгать некомфортно и часто maxspeed:practical=40. Опять же, не забываем отрезать “гонщиков”, который плюют на комфорт. А так, да, много есть мест, где можно разогнаться. И разгоняются, посему там и впрямь можно ставить maxspeed:practical=90.
Но как я писал, что брать надо максимум из maxspeed:practical и maxspeed (или тем, что для себя водитель считает максималкой на данной дороге maxspeed+20 и т.п.).
Поэтому легальный навигатор должен все одно предполагать, что по Питеру вы поедите 60 и планировать маршрут из этого.
А навигатор и скорой или полиции может не учитывать maxspeed, а брать maxspeed:practical, да еще и прибавлять немного, жертвуя комфортом.

  1. Люди ездят, в основном, глядя не на ГАЙцев, а на состояние дороги. Посему их максимальная комфортная скорость — вполне объективный показатель именно качества дороги. Да есть ограничение сверху, накладываемое наличием правил ПДД, отчего показатель неточен, если больше макс. разрешенной.
  2. Для навигатора совсем неважно. почему местные ездят по дороге 80, от колдобин или от наличия кучи ползущих фур. Это статистический параметр. Наиболее вероятно, что вам попадется именно среднее количество фур.

Из этого он должен планировать время прибытия. А маршрут строить с учётом в первую очередь исходя из 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.

Спорно. Я езжу по плохим дорогам по принципу “больше скорость - меньше ям”, но с радостью объеду этот участок, пусть и в три раза дальше. И поеду даже медленнее, соблюдая ПДД и наслаждаясь движением по ровному шоссе.

Вы никогда не пробовали добиться абсолютно идеального роутинга в отдельно взятом городке, что бы СитиГид (например) из любой точки в любую вёл так, как поехал бы местный? Для решения задачи одобнее ставить сразу цифры, а не “колдовать” с сочетаниями smoothness, surface:grade и т. п.

Под “тюнингом” подразумевается рихтовка данных OSM под конкретный рендер маршрутизатор?

В покетгис есть простая настройка: 5 градаций между Быстрее и Короче.
Так я подозреваю, что самый массовый выбор это пара самых быстрых случаев.

Можно придумать другие — дело нафигатора. А вот адекватные данные для реализации минимизируемой функции (время или расстояние или их смесь или количество ударов по задницех на кочках) вполне можно и должно расставлять в ОСМ.

Это типичное предложение “рисовать под рендер”.
Если использовать некий тег не в качестве объективной физической величины, в качестве костыля для конкретной (несовершенной) программы, сразу возникает вопрос - под какую конкретно программу мы “рихтуем” данные OSM?

  • под Навител навигатор?
  • под Гармин?
  • под 7 дорог?
  • под Ситигид?
  • под iGO?

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

Пока там “данные” для тюнинга конкретного маршрута, то иначе им и пользоваться не будут. Ждем адекватных данных.

Если исходить из этого, то тег в виде maxspeed:practical совершенно неприемлем.
Может быть только maxspeed:citygid:practical, maxspeed:garmin:practical, maxspeed:igo:practical…
Да еще с многочисленными уточнениями, зависящими от настроек конкретной программы, потому как обычно в программах маршрутизации поддерживается несколько режимов прокладки маршрута.

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

maxspeed:practical должен содержать именно время нормальной езды, а не некое значение некой целевой функции некоего навигатора :slight_smile:
Просто конверторы и навигаторы ничего другого понимать не хотят, вот и получился один рычаг на все случаи жизни. :smiley:

Мне кажется что модераторам давно пора переименовать тему …

Вынес в отдельную тему.

Напоминаю, что этот вопрос уже обсасывали (кому не лень, - найдите старую тему), и выяснили, что никто толком не понимает, что же такое maxspeed:practical. Основной вариант тогда был “комфортная скорость среднего авто, чтобы не сильно напрягать подвеску” :smiley:

Тогда же для желающих тюнинговать маршруты в навигаторах придумали тег avgspeed - “средняя прогнозная скорость”.

Безусловно.

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

Мне кажется, обсуждение пора переводить в конструктивное русло, способное привести, по меньшей мере, к созданиюв wiki странички RU:Key:maxspeed;practical с вполне конкретным и одобряемым более или менее всеми содержанием.
Для этого, мне кажется, нужно сделать 2 шага:

  1. Убедить сомневающихся, что в OSM не место не имеющим физического смысла настроечным коэффициентам под конкретный режим работы конкретной программы, какими бы благими целями это ни прикрывалось.
  2. Определиться с формулировкой физического смысла величины maxspeed;practical. На этот счет, как я понимаю, существует две основные точки зрения:
минимум из 3-х величин:
1. Ограничения по ПДД.
2. Ограничения по физическим характеристикам дороги (качество покрытия, извилдистость и пр.)
3. Ограничения, связанные с загруженностью дороги, пешеходами и пр.

минимум их 2-х величин (ограничения ПДД полностью игнорируются):
1. Ограничения по физическим характеристикам дороги (качество покрытия, извилдистость и пр.)
2. Ограничения, связанные с загруженностью дороги, пешеходами и пр.

Каждый из вариантов имеет свои плюсы и минусы, остановлюсь на таковых для второго варианта:

  • если значение maxspeed;practical > maxspeed, то оно просто может быть проигнорировано программами, которым нужен первый вариант.
  • значения не ограниченной посредством ПДД скорости весьма субъективны: с одной стороны, не так мало машин, максимальная скорость которых не превосходит 130 км/ч (например, внедорожники), а с другой - этот тег может превратиться в поле битвы людей, желающих чем-то померяться, например, максимальной скоростью своего автомобиля. Отсюда - неизбежная война правок.

Лично я за первый вариант.