highway= stop и highway=give_way

Sergey_Astakhov · 2011-09-07T10:23:39.000Z

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

j-wills · 2011-09-07T10:29:55.000Z

Sergey Astakhov:

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

А как к OSM автор конвертера относится ?
Ну разве что как и все только наполняет её…

Vitalts · 2011-09-07T10:38:14.000Z

Если вей “очень короткий”, то скорее всего, что знака либо не существует на местности, либо он установлен в обе стороны. Третьего придумать не могу.

Да любой перекресток, где второстепенная одновейная дорога перед перекрестком имеет ответвление для поворота направо

–

highway[:forward|]=<give_way>|…

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

VikDD · 2011-09-07T10:49:51.000Z

Изменение направления вея ломает очень много чего, те же incline’ы, ещё хуже, когда он oneway=yes, там изменение направления ещё хуже сказывается.

Vitalts:

Да любой перекресток, где второстепенная одновейная дорога перед перекрестком имеет ответвление для поворота направо

Ну и - в чём проблема ставить точку на “второстепенном” вее?
Или я не понимаю? Я просто реально не понимаю ситуацию, когда знак физически стоит, а в ОСМ он “не помещается”. Можно ссылку на место или просто картинку?

Ilis · 2011-09-07T10:52:26.000Z

Знак стоит не на дороге, а сбоку, чаще всего геометрически ближе к пересекаемой дороге.

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

Vitalts · 2011-09-07T11:00:19.000Z

Изменение направления вея ломает очень много чего, те же incline’ы, ещё хуже, когда он oneway=yes, там изменение направления ещё хуже сказывается.

oneway=yes, кстати, JOSM не ломает, про incline не знаю

Ну и - в чём проблема ставить точку на “второстепенном” вее?

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

Знак стоит не на дороге, а сбоку, чаще всего геометрически ближе к пересекаемой дороге.

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

VikDD · 2011-09-07T11:52:39.000Z

Вы предложите схему. Пока то, что есть - хотя как-то может быть обработано. То, что предлагается сделать отношением - вообще не ясно и не понятно. Как это будет выглядеть?
По поводу “поломать”. Релейшн ломается в 100 раз легче, чем вей.

Vitalts · 2011-09-07T12:46:16.000Z

При поломке отношения, его легче отследить, ибо нарушается конструктивность.

Сходу пример на суд:


отношение:
type = traffic_sign
traffic_sign = give_way, stop, ... (считаю не обязательным, ибо есть линк на знак)

участники:
Точка  sign   кол-во = 1, пой знака
Вей     via     кол-во = 1, хайвей, на который распространяется знак
Точка  from  кол-во = 0..1, задает направление движения действия знака, в случае если to не является концом вея.
Точка  to      кол-во = 1, точка на вее, в направлении которой действует знак, для рассматриваемых знаков, идеал - точка перекресток

Хайте, вместе найдем наилучшее решение.
Или, все же, ПОИ знака оставить в покое, пусть будет сам по себе, и вот это:


traffic_sign = give_way, stop, ...

оставить, такая конструктивность уже стала стандартом для отношений, и вот это:


Точка  sign   кол-во = 1, пой знака

из отношения выкинуть

dr_mx · 2011-09-07T13:10:38.000Z

Вот, уже думал. тынц

Vitalts · 2011-09-07T13:39:27.000Z

dr&mx, sign на хайвее? В реале знак же не на дороге ставится.

dr_mx · 2011-09-07T14:10:10.000Z

не на дороге - там где он стоит в реале. а некоторые над дорогой висят
в отношении описываешь примерно так

Type=junction

via=место пересечения дорог
major=вей главной дороги
sign=точка знака главной дороги (если есть) или стоп (для жд переездов?)
major=вей главной дороги
sign=точка знака главной дороги (если есть) или стоп (для жд переездов?)
minor=вей второстепенной
sign=точка знака уступи (если есть)
minor=вей второстепенной
sign=точка знака уступи (если есть)
minor=вей второстепенной
sign=точка знака уступи (если есть)

Sergey_Astakhov · 2011-09-07T14:31:46.000Z

IMHO, отношение лучше делать на весь перекрёсток
Типа такого:

Свойства:
type=crossing
crossing=controlled/uncontrolled

Роли:

main_road - главная
minor_road - второстепенная
outline - границы перекрёстка

Точки give_way/stop остаются как есть.

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

dr_mx · 2011-09-07T14:51:24.000Z

Каков алгоритм расчёта? Может вы знаете волшебную формулу? Без учёта трафика?

Когда весь перекрёсток состоит из более чем двух дорог или некоторые имеют две проезжие части очень трудно описать приоритеты.
А когда отношение описывает только пересечение в точке, то уже просто задать их. И например primary_link будет главнее primary

Vitalts · 2011-09-07T16:04:36.000Z

dr&mx, не на дороге - это хорошо, но возникают трудности с определением направления действия знака в случае не разделенного вея на перекрестке. Лучше добавить признак, явно указывающий направление действия знака, иначе проблем не оберешься. ИМХО, заставлять бить вей на перекрестке тоже не хорошо.

Ilis · 2011-09-07T16:26:10.000Z

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

Т. е. в случае поворачивающей главной имеем: на второстепенной уступаем тем, кто на главной слева, на главной спереди и на второстепенной справа, а на главной уступаем тем, кто на главной справа.

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

Sergey_Astakhov · 2011-09-07T16:29:20.000Z

dr&mx:

Каков алгоритм расчёта? Может вы знаете волшебную формулу?

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

К примеру в том же Ситигиде сейчас зашиты единые стоимости левого/правого поворота. Если б они добавили в свой конвертер расчёт индивидуальных стоимостей с учётом приоритетов - маршруты бы улучшились. Благо в самой программе у них и так почти всё есть для этого (статистика в карте, векторные пробки по направлениям и т.п.)

dr&mx:

Без учёта трафика?

Учёт трафика - это уже статистика/пробочный сервис. Пускай этим специализированные сервисы занимаются.

dr&mx:

Когда весь перекрёсток состоит из более чем двух дорог или некоторые имеют две проезжие части очень трудно описать приоритеты.
А когда отношение описывает только пересечение в точке, то уже просто задать их. И например primary_link будет главнее primary

В ПДД нет разделения “более главная дорога”/“менее главная дорога”. Есть только главная, второстепенная и помеха справа. Согласно этому и нужно определять приоритетность.

Sergey_Astakhov · 2011-09-07T16:32:43.000Z

Ilis:

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

Т. е. в случае поворачивающей главной имеем: на второстепенной уступаем тем, кто на главной слева, на главной спереди и на второстепенной справа, а на главной уступаем тем, кто на главной справа.

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

Всё расписывать отдельно - это будет по одному relation на каждое направление движение к перекрёстку. Вручную это расписать и поддерживать будет нереально.

dkiselev · 2011-09-07T17:27:20.000Z

Плюсую аутлайн - тогда в навигаторе с легкостью генериться крупная картинка со схемой проезда перекрестка.

Ilis · 2011-09-07T18:08:39.000Z

Sergey Astakhov:

[Всё расписывать отдельно - это будет по одному relation на каждое направление движение к перекрёстку. Вручную это расписать и поддерживать будет нереально.

По одному релейшену на каждое «Уступи дорогу». Т. е. для классического перекрёстка это два релейшена со второстепенки с двух сторон, а для поворачивающей главной это будут два релейшена для второстепенной и один для главной, у которой помеха справа. Плагин их без труда расставит Зато конвертеру не надо будет мучиться.

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

dr_mx · 2011-09-07T18:12:03.000Z

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