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

Вот именно - если кому-то нужна средняя скорость или скорость протока, - пусть будет, но только не в тега семейства maxspeed.

А смысл как раз в том, чтобы при прокладке маршрута избегать дорог с maxspeed:practical существенно ниже maxspeed, и тем самым повысить прогнозируемость времени прохождения маршрута.
Очевидно, в случае, когда maxspeed:practical > maxspeed сделать такое становится принципиально невозможным, что явно ограничивает прогресс алгоритмов маршрутизации.
maxspeed:practical должна оказать помощь при прокладке маршрута, а при сегодняшнем состоянии разнобоя мнений она эту функцию выполнять не может.
Это как раз тот случай, когда некоторое количество внесенной в базу недостоверной информации препятствует вообще любому использованию этого поля, т.к. нет возможности различить, где “полезное” значение, а где - ошибочное.

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

Что бы использую этот параметр можно было построить оптимальный маршрут. При этом даже не важны сами цифры, главное в их относительности в данной местности.
Например, есть две дороги. На одной не разогнаться более 20 км ч, иначе зубы и пружины повылетают нафик. На другой идеальный асфальт, но из за пешеходных переходов, светофоров, искусственных неровностей скорость то же не превысит 20 км ч. Где лучше ехать? Лично я поеду по асфальту, даже если путь будет в три раз длиннее и потрачу в три раз больше времени. Соответственно и разницу в max_speed:practical делаю в три раза. (Можно сказать, читываю время на последующий ремонт подвески, лечение расшатанных нервов).

Вот как то так. Вижу, что с “отчетливо сформулировано” у меня туговато…

Именно это она и делает в ее теперешнем понимании - скорость, предназначенная для оценки времени прохождения участка дороги.
Почему она maxspeed:practical, а не speed:practical, надеюсь, понятно? Ответ ведь лежит на поверхности. Подсказка - maxspeed:practical расставлена не везде.

Не рисуйте под потребителя данных?? :slight_smile: andriano, возьмите свои слова обратно, пожалуйста. У нас уже есть сферический footway в вакууме, его вполне достаточно.

Не говорите загадками. Кому то просто не понятно. А кому то настолько больше Вашего понятно, что он не знает, что конкретно имеется в виду. :slight_smile:

это не выдумка, а научный термин :slight_smile:
Тем не менее, я тоже считаю, что maxspeed:practical не должна превышать maxspeed. Нельзя прокладывать маршрут с рачётом на то, что “авось проскочу здесь побыстрее, авось меня не оштрафуют”.
ИМХО, значение maxspeed:practical нужно определять как минимальное из трёх чисел:

  1. макс скорость, допускаемая ПДД на этом участке (maxspeed)
  2. макс скорость, допускаемая состоянием дороги (ямы, колдобины), рельефом (крутые повороты, спуски-подъёмы), ограничения обзорности.
  3. макс скорость, достижимая с учётом помех от других участников дорожного движения (заторы, пешеходы-самоубийцы)

Нет.
От того, что мы что-то добавляем к тегк maxspeed, он не перестает быть “max”.

Это противоречие возникает исключительно от той ошибки, которую ВАы допустили в исходном предположении.
Как только мы понимаем, что maxspeed всегда остается maxspeed и никогда не превращается в averagespeed, все становится на свои места.

Вот именно: как только мы пытаемся впихнуть в maxspeed что-то вроде averagespeed, то так или иначе наталкиваемся на неоднозначности или противоречия.
По-хорошему, maxspeed:practiacal должно указывать на единственное обстоятельство: проехать по этой дороги со скоростью равной maxspeed невозможно или, минимум, небезопасно. Отсюда сразу важный вывод: если maxspeed:practiacal явно указывается, ее величина должна минимум на 10 км/ч быть меньше maxspeed. В противном случаев никакой необходимости в ее указании нет, что в принципе должно означать “дорога вполне соответствует требованиям ПДД и существующих стандартов”.

Соответственно, в тех странах, где это требование выполняется практически для всех дорог, тег maxspeed:practiacal не нужен, что и показали результаты голосования.

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

А во введении упомянуть, что хотя в международном голосовании этот тег провален, для России он имеет актуальность и широко используется вследствие двух извечных российских проблем (одной из которых соответствует п.2, а другой - п.3).

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