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

andriano · 2012-11-27 12:20:06

Sergey Astakhov wrote:

Всё бы вам чужие теги испортить. Сделайте себе уже maxspeed:andriano и устанавливайте там какие хотите правила.

1. Чтобы что-то испортить, оно должно быть перед этим исправно. На настоящий момент реально используемый тег maxspeed:practical этим свойством не обладает, т.к. отсутствуют правила его применения, и каждый мапит кто во что горазд.
2. Я не пытаюсь установить какие-то свои правила, я лишь хочу добиться, чтобы правила были одинаковы для всех. Кстати, чтобы понять это, достаточно лишь окинуть взглядом мое предложение, в котором содержится на выбор более одного варианта правил. Мне, в общем-то, не очень важно, какой именно вариант будет принят, для меня важно, чтобы он был един для всех и не противоречил здравому смыслу (т.е. чтобы можно было не только его проставлять, но еще и им пользоваться).

dimuzz · 2012-11-27 12:25:55

Еще раз: все предлагаемые уважаемым andriano варианты есть способы оценки практической скорости. Нет вижу никаких проблем использовать их как дополнение к статистически достоверным измерениям, но только как дополнение, как оценку. Если измерения дают скорость выше ПДД, с этим можно только смириться как с медицинским фактом.

andriano · 2012-11-27 12:26:52

dimuzz wrote:

andriano wrote:
80% - это что-то наподобие медианы, которая есть способ подсчета среднего.
Что-то новое в математике.
Всегда считал, что это значение, которое заданная случайная величина не превышает с фиксированной вероятностью.

Новое в математике - это наверняка. Хотя бы потому, что статистика на ограниченной выборке и вероятность имеют довольно мало общего.

Что же касается случайных величин, то в данной теме я их обсуждать не готов. (да и вообще IMHO им не место в OSM)
Меня интересует лишь единообразное применение определенного тега, для чего, по моему мнению, необходимо достаточно подробное описание его применения.

andriano · 2012-11-27 12:32:39

dimuzz wrote:

Еще раз: все предлагаемые уважаемым andriano варианты есть способы оценки практической скорости.

Нет.
Я предлагаю исключительно варианты оценки ограничения скорости сверху. Вариант оценки скорости я упомянул лишь один (avgspeed) и то лишь с целью отделить ограничение скорости от самой скорости. И если у кого есть соображения по оценке скорости (а не ограничения скорости), очень прошу делать это в другой теме. Во избежание путаницы.

wowik · 2012-11-27 13:27:19

-

Last edited by wowik (2012-11-27 13:30:41)

wowik · 2012-11-27 13:27:52

andriano wrote:

Как бы мы не подбирали веса ребер, нам не удастся добиться, чтобы сумма весов для синего пути оказалась меньше, чем для красного. Даже если мы готовы отказаться от равенства весов ребер.

Это лечится "учетом движения по полосам", то есть граф становится сложнее — у перекрестка сворачивающие получают свою дугу со своей скоростью.
Ну или дуга вырождается в точку — штраф за поворот, который тяжелее померить, чем время нахождения на дуге поворота.

Last edited by wowik (2012-11-27 13:30:26)

SevenMag · 2012-11-27 13:28:52

А если учесть горные дороги, хоть и по прямой и по асфальту, в одну сторону 110 едишь и притормаживать надо, а обратно до 40 падает. Это что, еще и по направлениям делить maxspeed:practical ? Поставил этот тэг (или подобный, не помню какой посоветовали) только один раз, и на очень опасном участке дороги, "тещин язык", где бьются даже знающие.
Мне кажется чтобы учавствовала скорость при расчете дороги, надо много много учесть критерием (можность, загруженость, опыт). Все не запихаешь в OSM.

Last edited by SevenMag (2012-11-27 13:31:32)

wowik · 2012-11-27 13:32:09

SevenMag wrote:

А если учесть горные дороги, хоть и по прямой и по асфальту, в одну сторону 110 едишь и притормаживать надо, а обратно до 40 падает. Это что, еще и по направлениям делить maxspeed:practical ?

Ага. maxspeed:practical:forward/...
Это не так сложно, как по часам суток и по дням недели (maxspeed:practical:conditional).

Надо перестать думать об этом теге, как о том, что надо расставлять руками.
Одни программки расставили, другие подхватили и распихали по навигаторам.

Last edited by wowik (2012-11-27 13:35:04)

andriano · 2012-11-27 14:15:39

wowik wrote:

Это лечится ...то есть граф становится сложнее...

Правильно.
Но сам факт такого "лечения" говорит, что любая попытка ввести объективный параметр на базе "упрощенного" графа - занятие бесперспективное.

andriano · 2012-11-27 14:24:37

SevenMag wrote:

Это что, еще и по направлениям делить maxspeed:practical ?

Вы будете смеяться, но это давно предусмотрено в OSM: http://wiki.openstreetmap.org/wiki/Key:conditional

Мне кажется чтобы учавствовала скорость при расчете дороги, надо много много учесть критерием (можность, загруженость, опыт). Все не запихаешь в OSM.

В принципе, насчет множества критериев - Вы абсолютно правы.
А вот насчет "все не запихаешь" - не согласен. Уже сейчас в OSM намного больше параметров, чем по факту используется современными маршрутизаторами. Что оставляет возможность разработки более совершенных алгоритмов маршрутизации на основе учета бОльшего количества параметров.

wowik · 2012-11-27 14:30:47

andriano wrote:

Но сам факт такого "лечения" говорит, что любая попытка ввести объективный параметр на базе "упрощенного" графа - занятие бесперспективное.

Так предлагается таки лечить. Не так уж много случаев, когда всё безнадежно плохо. Да, на коротких участках скорости зависят от направления движения, ну и что? В первом приближении можно усреднять, в следующем — разделять потоки и т.п. Нет предела совершенству.

Last edited by wowik (2012-11-27 14:36:05)

andriano · 2012-11-27 14:50:13

wowik wrote:

Так предлагается таки лечить. Не так уж много случаев, когда всё безнадежно плохо. Да, на коротких участках скорости зависят от направления движения, ну и что? В первом приближении можно усреднять, в следующем — разделять потоки и т.п. Нет предела совершенству.

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

И, раз уж зашла об этом речь: возвращаясь к сообщению chnav'а, где он объяснял принципы работы маршрутизаторов, хотелось бы заметить, что разработка польского формата относится ко времени первых гарминов. Вполне естественно, что в то время для прокладки маршрутов использовался простейший алгоритм Дейкстры. Но у меня нет уверенности, что за 20 лет ничего не изменилось. Тем более, что адаптация Дейкстры под учет чувствительного к смене направления движения веса вершин не представляет большой проблемы. По крайней мере, не влияет ни на вычислительную сложность, ни на способы организации работы алгоритма.

Last edited by andriano (2012-11-27 14:57:10)

esaulenka · 2012-11-27 15:07:28

Я вот одного не понимаю - о чём тут полторы сотни сообщений?

Есть реально существующий софт. Да, он неидеальный. Да, для корректной работы ему требуется некоторое количество костылей (и maxspeed:practical - один из). Но он ЕСТЬ. Он худо-бедно РАБОТАЕТ.

А вот идеального роутера, который сам автоматически просчитывает все ограничения, почему-то нету. Идей, да, идей на 100500 программ хватит.
Может, сначала его таки сделать, а потом кричать "долой костыли! они могут принудить бедного пользователя преступить закон!!". А, господа теоретики?

andriano · 2012-11-27 19:50:32

esaulenka wrote:

А вот идеального роутера, который сам автоматически просчитывает все ограничения, почему-то нету. Идей, да, идей на 100500 программ хватит.
Может, сначала его таки сделать, а потом кричать "долой костыли! они могут принудить бедного пользователя преступить закон!!". А, господа теоретики?

Проблема в том, что если есть далеко не идеальный роутер, идеальный роутер, и данные, искусственно заточенные под неидеальный роутер, то идеальный роутер на этих данных будет работать хуже неидеального. Хотя мог бы лучше.
Тезис "не рисуйте под рендер (под роутер)" родился не просто так. ПРактика "рисовать под рендер" на корню убивает возможность улучшения алгоритмов.

Так что "сначала сделайте роутер" - принципиально невозможно. Без "правильных" данных невозможно даже объективно сравнить два алгоритма, а тем более выбрать из алгоритмов лучший.

PS. Не вижу ничего удивительного в том, что, не читая тему, нельзя понять, о чем она.

dimonster · 2012-11-29 17:38:13

А у меня уже появилось сомнение в необходимости этого тега maxspeed:practical
Почему он не нужен:
1) он отвергнут при голосовании
2) есть разногласия в понимании сути этого тега и, как следствие, разными людьми значение параметра проставляется по разному
3) значение maxspeed:practical может меняться в зависимости от времени суток, от заторов на соседних улицах и т. д.
4) для разных транспортных средств может быть разное значение maxspeed:practical.
5) значение будет разным для разных полос одной и той же дороги, а также для разных направлений одной и той же дороги
6) состояние дороги (тип покрытия, состояние покрытия, продольный уклон) уже указывается в других соответствующих тегах.
Причём эти параметры можно явно и наглядно оценить или измерить независимо от личного мнения наблюдателя.
7) учёт помехи от других участников дорожного движения, которые влияют на значение maxspeed:practical - это работа для онлайнового пробокосервиса.

Ilis · 2012-11-29 17:51:18

dimonster wrote:

2) есть разногласия в понимании сути этого тега и, как следствие, разными людьми значение параметра проставляется по разному
3) значение maxspeed:practical может меняться в зависимости от времени суток, от заторов на соседних улицах и т. д.

Пункт 3 зависит от пункта 2

Значение maxspeed:practical не может меняться в зависимости от времени суток и заторов если показывает максимально достижимую большей частью (80 %, например) автомобилей скорость в наиболее благоприятных условиях.

Sergey Astakhov · 2012-11-29 18:24:47

dimonster wrote:

Почему он не нужен:
1)
...
7)

Вы сейчас перечислили пункты согласно которым навигаторы без пробок нормальные маршруты прокладывать не могут в принципе. Однако думаю, что большинство пользователей таких навигаторов за пределами Москвы и Питера с вами не согласятся.

Amigo · 2012-11-29 18:27:51

dimonster wrote:

А у меня уже появилось сомнение в необходимости этого тега maxspeed:practical
2) есть разногласия в понимании сути этого тега и, как следствие, разными людьми значение параметра проставляется по разному

Для статистики есть ли здесь кто проставлял этот тег для чего либо иного кроме как для тюнинга маршрутизации?

mixdm · 2012-11-29 20:38:26

есть ли здесь кто проставлял этот тег для чего либо иного кроме как для тюнинга маршрутизации?

Сильно сомнения есть в том, что кто то будет ставить этот тег для чего то другого... В отличии от множества различных тегов этот пользу приносит для реально существующих программ навигации, а какое в нем значение - это уже как то вторично... Если не нравится кому - так создайте свои теги и поддерживайте, но не надо ломать то, что уже работает...

j-wills · 2012-11-30 04:38:15

Товарищи, не надо мудрить с днями/часами!!! Во-первых, если падает пропускная способность у дороги в час пик - она падает у всех дорог в округе! А динамические изменения дорожной ситуации призван бдеть, как сказал dimonster, пробковый сервис!
Да и вперёд/назад - тоже излишне! Если дорогу загромождают машинами, то на обоих сторонах, если дорога хреновая - то вся (направления - оч частные случаи: ремонты и т.п.)

Демогогия и забюрократизированость (быть или не быть) - основные проблемы для хороших вещей в нашей стране!

З.Ы. можно как-нибудь роботом ради эксперимента по трекам вычислить среднюю максимальную скорость на каком-нибудь шоссейном участке?

Last edited by j-wills (2012-11-30 04:39:15)

SevenMag · 2012-11-30 06:07:17

j-wills wrote:

Да и вперёд/назад - тоже излишне! Если дорогу загромождают машинами, то на обоих сторонах, если дорога хреновая - то вся (направления - оч частные случаи: ремонты и т.п.)

Забыл крутые подъемы спуски. В наших районах их много, горы, что ж сделаешь.

j-wills · 2012-11-30 06:46:18

SevenMag wrote:

Забыл крутые подъемы спуски. В наших районах их много, горы, что ж сделаешь.

На подъём/спуск тэг incline есть! Даже можно градусы уклона выставлять! А направление - направление линии.
Кстати, было б неплохо его учитывать в навике вкупе с maxspeed
А если предложенным тэгом обозначать, то разница не столь уж большая, а на серпантине что вверх, что вниз - особо то не разгонишься, если не камикадзе, конечно!

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

Пока мы стираем обычным порошком, Малахов с Тайдом уже у Гугла

Не подходит под конкретный случай - не обозначайте пока, а занимайтесь тем, чем можете!
Это как в школе: запнулся на задаче, не сиди над ней, иначе остальные 10 до звонка не решишь...

А с пологими дорогами - корень проблемы находится в правовом нигилизме. Бюргеры, например, если написано 50, а дорога позволяет и 150, будет ехать 50, в отличии от наших бравых хлопцев

Last edited by j-wills (2012-11-30 07:41:21)

Amigo · 2012-11-30 07:08:26

Убедительная просьба, если все-таки решитесь порушить существующие значения maxspeed:practical, то хотя бы перенести текущие значения в тег avgspeed.

SevenMag · 2012-11-30 07:09:29

j-wills wrote:

На подъём/спуск свой тэг есть
А если предложенным тэгом обозначать, то разница не столь уж большая, а на серпантине что вверх, что вниз - особо то не разгонишься, если не камикадзе, конечно!

Не каждая горная дорога - серпантин. Да и не про саму горку говорил а про скорость на ней. У нас они прямые и длинные, если с горки 110-130 и тормозом придерживаешь, то в горку если перед ней разогнаться, под конец 20-30 получается (это по собственному опыту, но все зависит от мощности и загрузки). Кстати на таких дорогах у нас ящики с песком на обочинах стоят.
Согласен что такого мало, но если уж обозначать maxspeed:practical то в некоторых местах надо учитывать направление.

Last edited by SevenMag (2012-11-30 07:10:15)

j-wills · 2012-11-30 07:24:10

SevenMag, ну, ещё в последствии можно ввести вариацию на тему maxspeed:hcv:practical - хотя, это лишнее, так как тэг отображает характеристику дороги, а не того, что едет по ней.

Last edited by j-wills (2012-11-30 07:47:18)

Announcement

#151 2012-11-27 12:20:06

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

#152 2012-11-27 12:25:55

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

#153 2012-11-27 12:26:52

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

#154 2012-11-27 12:32:39

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

#155 2012-11-27 13:27:19

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

#156 2012-11-27 13:27:52

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

#157 2012-11-27 13:28:52

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

#158 2012-11-27 13:32:09

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

#159 2012-11-27 14:15:39

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

#160 2012-11-27 14:24:37

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

#161 2012-11-27 14:30:47

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

#162 2012-11-27 14:50:13

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

#163 2012-11-27 15:07:28

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

#164 2012-11-27 19:50:32

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

#165 2012-11-29 17:38:13

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

#166 2012-11-29 17:51:18

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

#167 2012-11-29 18:24:47

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

#168 2012-11-29 18:27:51

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

#169 2012-11-29 20:38:26

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

#170 2012-11-30 04:38:15

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

#171 2012-11-30 06:07:17

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

#172 2012-11-30 06:46:18

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

#173 2012-11-30 07:08:26

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

#174 2012-11-30 07:09:29

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

#175 2012-11-30 07:24:10

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

Board footer