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

ИМХО, проблема одна - “дураки”. А проблема дорог - это уже следствие из первой проблемы :slight_smile:

Кстати, насчёт “помех от других участников дорожного движения” и их влияния на maxspeed:practical ещё есть что обсудить. Дело в том, что эти помехи неоднородны по времени. Утром пробки, в обед - нормально, вечером пробки, ночью - пусто, хоть поперёк дороги катайся.

Может, при расчёте maxspeed:practical следует учитывать только maxspeed и состояние (раздолбанность) дороги, а загруженность участка дороги трафиком пусть во всяких там онлайновых пробкосервисах учитывают?

А я считаю может, 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:

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