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

Sergey Astakhov · 2012-12-01 15:17:32

Эцелоп wrote:

Достаточно простого "дорога_может_не_чиститься от снега=yes"

http://wiki.openstreetmap.org/wiki/Key:snowplowing

Эцелоп · 2012-12-01 15:29:47

Эх, перевёл бы кто. Для России актуально.

CupIvan · 2012-12-01 16:33:00

перевел, это скорее для северных стран с постоянными снегопадами...

Эцелоп · 2012-12-01 16:42:18

CupIvan wrote:

перевел, это скорее для северных стран с постоянными снегопадами...

Спасибо. Вроде подходит, если ставить его только на дороги, где с этим проблемы.

andriano · 2012-12-01 18:32:09

CupIvan wrote:

перевел, это скорее для северных стран с постоянными снегопадами...

Вы умышленно вместо "может принимать любые значения, наиболее осмысленными среди которых являются:" написали: "может принимать следующие значения".

PS. Интересно, как тегировать дорогу, которая чистится 1-3 раза за зиму.

Last edited by andriano (2012-12-01 18:34:47)

andriano · 2012-12-01 18:49:10

Вы не находите, что эти два высказывания противоречат друг другу (если, конечно, второе относится к maxspeed:practical)?

Эцелоп wrote:

Алгоритм такой. Есть две дороги. Берём длину каждой в км и делим на maxspeed:practical. Сравниваем. Используем как единственный или как дополнительный параметр для выбора маршрута. Если получается правильно, "как ездят местные" - отлично. Если нет - правим тег (теги). Всё. Программы и алгоритмы пусть делают что хотят, мы свою задачу выполнили.

Эцелоп wrote:

Не больше не знаю, как Вас убедить, что качество и состояние дороги - это объективная характеристика.

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

Если Ваше настоящее мнение - это именно вторая цитата, то осталось только констатировать, что мы пришли к консенсусу.
Но, сказав "а", нужно будет сказать и "б": ни о каком подборе величины, заносимой в тег, под конкретную маршрутизацию в этом случае быть не может. Объективную физическую величину нельзя подбирать в принципе.

Эцелоп · 2012-12-02 23:34:08

Я примерно понимаю, что Вы хотите донести до меня. Но это имеет мало отношения к тому, что пытаюсь донести я.
Далее много букв, можете не читать.
[spoiler]И так, есть посёлок с сотнями причудливо переплетённых улиц. Задача - дать данные для идеальной маршрутизации, это важно, например, для "Скорой". Я знаю, как лучше проехать из любой точки А в любую точку Б. Даже если я проставлю все возможные теги, в отдельных местах маршрутизация будет не верной, слишком много параметров надо учитывать. Кроме того, это очень трудоёмко. И я хоть здесь и дилетант, подозреваю, что алгоритмам маршрутизации тогда то же будет непросто. Подгонять теги объективных характеристик не желательно, согласен. Нужен отдельный тег, чисто для маршрутизации. И maxspeed:practical вполне подходит. Тогда его значение - абстрактная величина, по возможности приближенная к практической скорости в км час. Неужели такая информация не нужна программам навигации?[/spoiler]

Ilis · 2012-12-03 04:32:09

Эцелоп wrote:

Подгонять теги объективных характеристик не желательно, согласен. Нужен отдельный тег, чисто для маршрутизации. И maxspeed:practical вполне подходит. Тогда его значение - абстрактная величина

http://bash.im/quote/413852

Ошибка: робот погибает при попадании в него гранаты (именно от попадания, а не от взрыва) Д - дизайнер, П - программист.
Д: программисты всё сломали! почему так получается?!
П: естественно так получается! потому, что у гранаты масса 100 кг! зачем вы это сделали?
Д: да?! а чтобы граната в воде тонула!
П: а почему она с нормальной массой не тонет?
Д: а потому что у воды плотность большая! (прим.: больше, чем у ртути)
П: а почему плотность такая большая?!
Д: а чтобы ящики деревянные плавали!
П: а почему они иначе не плавают?!
Д: а потому что у них масса 50 кг!
П: а зачем такая масса?!
Д: а иначе они некрасиво разваливаются!

andriano · 2012-12-03 08:30:47

Эцелоп wrote:

Нужен отдельный тег, чисто для маршрутизации. И maxspeed:practical вполне подходит. Тогда его значение - абстрактная величина, по возможности приближенная к практической скорости в км час. Неужели такая информация не нужна программам навигации?

Может, конечно, и нужен, но не в рамках OSM, т.к. противоречит его основополагающим принципам.

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

И еще раз призываю вернуться к конструктивному обсуждению. Т.е. не пытаться обсуждать то, что заведомо неприемлемо.

Эцелоп · 2012-12-03 08:41:18

andriano wrote:

то, что заведомо неприемлемо.

Неприемлимо по Вашему мнению.

dimonster · 2012-12-03 08:48:20

Угу. Так скоро придём к тегам, прямо указывающим "вес" ребра в дорожном графе для каждой навигационной программы и для каждой категории транспортных средств

kostyl:navitel:weight:maxspeed:practical:car:streetracer=240
kostyl:navitel:weight:maxspeed:practical:hgv=120
kostyl:navitel:weight:maxspeed:practical:car=160
kostyl:navitel:weight:maxspeed:practical:car:chaynik=40
kostyl:navitel:weight:maxspeed:practical:pedestrian=3

Эцелоп · 2012-12-03 09:02:35

dimonster wrote:

Так скоро придём к тегам, прямо указывающим "вес" ребра в дорожном графе для каждой навигационной программы

Не передёргивайте. Предлагается как раз универсальный тег, который могут использовать алгоритмы навигации.

dimonster wrote:

weight:maxspeed:practical:hgv=120

А вот это было бы неплохо.

andriano · 2012-12-03 09:05:41

Эцелоп wrote:

andriano wrote:
то, что заведомо неприемлемо.
Неприемлимо по Вашему мнению.

Вы хотите узнать мнение DWG по этому поводу?
Напишите им, указав, что maxspeed:practical - настроечный параметр, который, к тому же, был отклонен при состоявшемся обсуждении. Думаю, очень скоро он будет выпилен из базы роботом.

Я привел аргументы в пользу своей точки зрения. И при этом совершенно уверен, что DWG найдет эти аргументы убедительными.
Вы можете предоставить аналогичные по силе аргументы? Если "да" - предоставьте, и посмотрим, что на это скажет DWG.

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

andriano · 2012-12-03 09:09:49

Эцелоп wrote:

Предлагается как раз универсальный тег, который могут использовать алгоритмы навигации.

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

Нет, безусловно, алгоритмы могут использовать все, что душеньке угодно (как универсальные, так и неуниверсальные теги), вопрос в том, - насколько это использование (и эти алгоритмы) будут эффективны.

В любом случае, алгоритмы могут использовать объективные физические параметры. И в этом отношении настроечный параметр не имеет никаких преимуществ.

Эцелоп · 2012-12-03 09:15:15

Maxspeed:practical давно и успешно используется, и маперами и алгоритмами, вопреки всем законам математики . И даже тому, что его смысла не понимает отдельно взятый инженер с высшим образованием. Спорить больше не о чем. Надеюсь, выпиливать maxspeed:practical не предлагается?

andriano · 2012-12-03 09:20:08

Эцелоп wrote:

Maxspeed:practical давно и успешно используется, и маперами и алгоритмами, вопреки всем законам математики .

Это еще не говорит о том, что используцется именно в качестве настроечного параметра.

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

А судьи кто?

Спорить больше не о чем. Надеюсь, выпиливать maxspeed:practical не предлагается?

Диагноз таков:
если объективная физическая величина - оставлять,
если настроечный параметр - однозначно выпиливать.

Лично мое мнение: четко определить содержание физической величины, поправить существующее использование и впредь использовать только по прямому назначению.

Last edited by andriano (2012-12-03 09:21:24)

liosha · 2012-12-03 11:34:02

Garmin wrote:

ROUTE_SPD
Numeric
Gives the speed that should be used for calculating the route. This should be the average free flow speed of the road.

esaulenka · 2012-12-03 13:26:32

liosha, ну кто такой гармин?!
Тут идут обсуждения сферического софта в вакууме, который без малейших допущений и без единого костыля построит единственно верный маршрут.

Куда уж этим гарминам и навителам до andriano, который уже взялся диагнозы ставить...

liosha · 2012-12-03 13:35:00

esaulenka wrote:

Куда уж этим гарминам и навителам до andriano, который уже взялся диагнозы ставить...

Дык он вполне грамотные вещи говорит, хотя и в слабо доходчивой форме

И что тег не пойми о чём, и что правила его заполнения надо определить, и что "настроечный коэффициент" сам по себе особого смысла не имеет.

Sergey Astakhov · 2012-12-03 14:53:54

liosha wrote:

И что тег не пойми о чём, и что правила его заполнения надо определить, и что "настроечный коэффициент" сам по себе особого смысла не имеет.

Ну так пусть предложит "самый правильный тег" с чёткими правилами заполнения и прочего. Получится удачным - будем пользоваться. Не получится - не будем.
Что за привычка переделывать чужие теги?

Last edited by Sergey Astakhov (2012-12-03 14:55:21)

dimonster · 2012-12-03 15:31:47

Ну, можно сразу "вес ребра графа" вписывать.
Нечто вроде "время, затраченное на перемещение от начала до конца участка". В секундах или минутах. Разное для разных категорий тр. ср.

elapsed_time:car=
elapsed_time:backward:car= ( в обратном направлении)
elapsed_time:hgv= (для грузовиков)
elapsed_time:bicycle=

LinFor · 2012-12-03 15:35:47

dimonster wrote:

Ну, можно сразу "вес ребра графа" вписывать.
Нечто вроде "время, затраченное на перемещение от начала до конца участка". В секундах или минутах. Разное для разных категорий тр. ср.

Хмм... А мне кажется эти данные можно автоматизированно из загруженных gps-треков собирать и экспортировать отдельно от основной базы OSM. Ибо сии параметры есть дело исключительно субъективное.

Amigo · 2012-12-03 15:47:06

Для тюнинга в ситуациях когда есть более длинная дорога высокого класса и короткая низкого и навику они одинаковы нужен стал именно

liosha wrote:

что "настроечный коэффициент" сам по себе особого смысла не имеет

и для этого вполне подошел maxspeed:practical подкуртив который на +- десяток км/ч на короткой или длинной дороге стало можно добиться правильной маршрутизации.

dimuzz · 2012-12-03 16:39:32

Ну и таки сошлюсь на Институт инженеров транспорта, который считает наиболее безопасной скоростью '85th percentile speed' (скорость, которую не превышает 85% водителей) и еще раз выдвигаю эту величину в качестве кандидата на инструментально измеримое значение maxspeed:practical. Насчет 80% был неправ
Кстати, судя по документу, в США вполне официально принято не выбирать speed limit с потолка, а принимать достаточно близким к '85th percentile speed'.
И, да, ИИТ в этом буклете прошелся и по распространенным заблуждениям типа "снижение официального предела скорости снижает скорость потока" или "снижение официального предела скорости снижает аварийность". Видимо, проблема несоответствия официального и практического скоростного режима актуальна не только в одной отдельно взятой стране...

andriano · 2012-12-03 16:57:34

Sergey Astakhov wrote:

Что за привычка переделывать чужие теги?

Я уже второй раз в этой теме слышу от Вас обвинение, что я, якобы, пытаюсь что-то "переделать".
Лично я вижу ситуацию так: до сих пор нее существовало единых правил заполнения этого тега, а я пытаюсь договориться об их формулировке. Т.е. не "переделать", а "упорядочить".
Вы, очевидно, видите ситуацию по-другому.
Ну так изложите свое видение:
- что было раньше?
- и чем это отличается от того, что я предлагаю?

Announcement

#226 2012-12-01 15:17:32

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

#227 2012-12-01 15:29:47

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

#228 2012-12-01 16:33:00

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

#229 2012-12-01 16:42:18

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

#230 2012-12-01 18:32:09

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

#231 2012-12-01 18:49:10

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

#232 2012-12-02 23:34:08

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

#233 2012-12-03 04:32:09

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

#234 2012-12-03 08:30:47

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

#235 2012-12-03 08:41:18

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

#236 2012-12-03 08:48:20

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

#237 2012-12-03 09:02:35

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

#238 2012-12-03 09:05:41

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

#239 2012-12-03 09:09:49

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

#240 2012-12-03 09:15:15

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

#241 2012-12-03 09:20:08

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

#242 2012-12-03 11:34:02

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

#243 2012-12-03 13:26:32

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

#244 2012-12-03 13:35:00

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

#245 2012-12-03 14:53:54

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

#246 2012-12-03 15:31:47

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

#247 2012-12-03 15:35:47

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

#248 2012-12-03 15:47:06

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

#249 2012-12-03 16:39:32

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

#250 2012-12-03 16:57:34

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

Board footer