turn restriction: неудобный стандарт

chnav · 2010-09-21 17:58:43

В продолжение http://forum.openstreetmap.org/viewtopi … 3358#p3358

К сожалению в текущей реализации turn restriction (from_way->via_node->to_way) приходится бить дороги. Назвать это иначе как подгонкой под системы навигации - язык не поворачивается.
Например в формате полиша каждый запрет описывается пятью параметрами: from_way->to_way и from_node->via_node->to_node. При этом дороги бить не надо, это происходит автоматически при компиляции полиша в бинарник (навител, гармин и т.д). По идее было бы достаточно только трех параметров (from_node->via_node->to_node), но в полише ноды имеют NodeID только если они роутинговые, и из одного роутингового нода до другого может быть несколько альтернативных веев.
Но в ОСМ _каждый_ нод имеет уникальный node_id ! Возникает вопрос - зачем надо было вводить мутную реализацию с веями, если каждый запрет однозначно описывается тремя нодами - via_node (то же что и сейчас), и по одному _ближайшему_ ноду на каждом из веев со стороны нужной для описания запрета, т.е. from_node->via_node->to_node. При этом полилинии разбивать не надо.

Текущая реализация в ОСМ:

Как описать то же самое без дробления вея:

Может это где-то уже обсуждалось в пропозалах, почему отказались от трех нодов, а приняли текущий стандарт с веями ?

Last edited by chnav (2010-09-21 18:03:25)

tmprec · 2010-09-21 18:03:23

Оба варианты было бы хорошо реализовать.

Last edited by tmprec (2010-09-21 18:03:55)

liosha · 2010-09-21 18:03:24

chnav wrote:

Но в ОСМ _каждый_ нод имеет уникальный node_id ! Возникает вопрос - зачем надо было вводить мутную реализацию с веями, если каждый запрет однозначно описывается тремя нодами - via_node (то же что и сейчас), и по одному _ближайшему_ ноду на каждом из веев со стороны нужной для описания запрета, т.е. from_node->via_node->to_node.

Кто-нибудь станет уточнять дорогу и добавит нод между этими двумя - и?
Формат, бесспорно, не самый удобный, но ничего лучше пока не придумали

tmprec · 2010-09-21 18:05:44

Кто-нибудь станет уточнять дорогу и добавит нод между этими двумя - и?

id нода, под который распространяется запрет, от этого не изменится.

chnav · 2010-09-21 18:07:36

При добавлении нодов ближайший нод (из новых добавленных) к node_via должен взять на себя роль from_node или to_node вместо предыдущего. Конечно это должно быть реализовано автоматически в редакторе, даже диалоговое окно юзеру показывать не надо.

Кстати так будет легче соединять веи, имеющие рестрикшины: после объединения запреты поворотов останутся без изменений.

Last edited by chnav (2010-09-21 18:16:24)

Ilis · 2010-09-21 18:13:59

liosha wrote:

Кто-нибудь станет уточнять дорогу и добавит нод между этими двумя - и?
Формат, бесспорно, не самый удобный, но ничего лучше пока не придумали

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

А вообще нынешней системе больше не хватает возможности добавить несколько членов с ролью "to"

dedNikifor · 2010-09-21 21:46:27

//А вообще нынешней системе больше не хватает возможности добавить несколько членов с ролью "to"

а зачем тебе несколько членов с такой ролью? )

osmisto · 2010-09-21 21:51:33

А чем плохо дробить? Мы же дробим, например, для maxspeed-а и для кусков с плохим surface. Хотя и то и другое можно было бы описать релейшином с двумя точками (start, end).

chnav · 2010-09-21 22:02:49

osmisto wrote:

Мы же дробим, например, для maxspeed-а и для кусков с плохим surface. Хотя и то и другое можно было бы описать релейшином с двумя точками (start, end).

Отличная идея, хотя в данном случае для однозначности лучше указать way_id+node_start+node_end, тогда можно создавать скоростные профили с любой детальностью. Дробить же веи для этого похоже на вандализм
Сложности с таким дроблением могут привести к тому, что раздробленые улицы мы начнем собирать обратно в рилейшены, например для того чтобы не менять одинаковые атрибуты у десятка веев вместо одного.

Last edited by chnav (2010-09-21 22:05:11)

osmisto · 2010-09-21 22:11:28

chnav wrote:

Отличная идея, хотя в данном случае для однозначности лучше указать way_id+node_start+node_end, тогда можно создавать скоростные профили с любой детальностью. Дробить же веи для этого похоже на вандализм

А как же перемещение точки? А если вей между точками все же разобьют, например, мостом. (сам себе противоречу: сначала сказал что можно через start/end, а теперь показываю что нельзя ... плохо поступил, знаю

Komяpa · 2010-09-21 22:11:31

Простите, а кому плохо от того, что вей раздроблен?

chnav · 2010-09-21 22:22:56

Это не плохо и нормально, если обусловлено объективными факторами (surface отличается, или еще какой-то атрибут). Но рилейшены являются надстройкой над примитивами, а получается наоборот - чтобы создать рилейшен "запрет поворота" мы вынуждены дробить примитив. По идее рилейшен должен создаваться на основе тех объектов которые уже есть, без любых других дополнительных условий типа дробления. Это примерно как при написании программы на C мы каждый раз лезли бы в ассемблерный код системных библиотек и правили их под сиюминутные нужды.

Last edited by chnav (2010-09-21 22:25:08)

chnav · 2010-10-07 08:44:29

Господа, требуется ваша помощь.
Как инициировать обсуждение варианта с тремя точками, описанного в первом посте ?
Я дробить дороги не хочу, рилейшены создаю (пока без загрузки на сервер), но толку от них мало, если они не будут использоваться в конечном формате для навигации. Еще меньше шансов выжить без поддержки такого типа в JOSM, а это уже требует внимания зарубежных коллег.
Куда следует постить свои предложения - в Relation:restriction/Proposals или Relation:restriction/Talk, или вообще связываться с авторами JOSM ? Каковы шансы что на эти страницы вообще кто-то зайдет ?
Спасибо!

Alexandr Zeinalov · 2010-10-07 08:47:07

Создаёшь пропозал в Proposed_Features/

chnav · 2010-10-07 09:18:04

Можно ли править Proposed Features по результатам обсуждения (что-то добавить, убавить, переименовать) ? Сомневаюсь что могу всё описать правильно с первого раза

Alexandr Zeinalov · 2010-10-07 09:45:41

http://wiki.openstreetmap.org/wiki/Proposed_features тут написано как всё делать. Пока пишешь draft - меняй как хочешь.

Surly · 2010-10-07 13:21:02

Alexandr Zeinalov wrote:

Пока пишешь draft - меняй как хочешь.

Когда после draft начнется стадия RFC — тоже можно менять (верно?).

VikDD · 2010-10-07 13:52:42

Рисую то, почему точка->точка->точка "не катят". Хотя об это уже ранее писалось...

Проблем именно в том, что кто-то вставит точку "между" start и via

Last edited by VikDD (2010-10-07 13:53:18)

chnav · 2010-10-07 14:13:15

Это понятно, JOSM надо править, чтобы рестрикшен изменялся автоматом. Зато минимум конфликтов при объединении веев.

VikDD · 2010-10-07 14:17:27

Честно признаюсь, из 2-х редакторов, которыми пользуюсь ни один не называется JOSM
Первоочередным должен быть potlatch, через него все начинают. Надо решить проблему в принципе, а не писать надстройки под конкретный редактор... текущая система наиболее понятна. Единственное что, нужно что бы в роли via мог выступать way или node->way->node.

siberiano · 2010-10-07 14:29:35

А почему бы не переделать роли: вместо from и to сделать from_forward, to_forward и from_backward, to_backward, чтобы было понятно откуда в каком направлении. Если в обоих направлениях запрещён левый поворот, просто 2 релейшена с теми же самыми путями.

Komяpa · 2010-10-07 14:33:33

А почему бы не провести по трём точкам вей, в котором написать restriction=yes? И запрет опишете, и релейшены не нужны.

PS: неудобство текущей схемы так и не было нормально обосновано.

siberiano · 2010-10-07 14:37:55

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

Кстати, у меня в josm плагин этот не работает, приходится всё делать вручную - создавать отношение, добавлять объекты, роли писать.

chnav · 2010-10-07 14:38:03

Я о том и говорю, что надо решать в принципе. Есть же Relation:destination sign, практически один-в-один то что я предлагаю.
Ну давайте назовем его не Turn Restriction, а, например, road_sign.
Дробить междугородные трассы ради примыкающей грунтовки с запретом "налево" - я не понимаю... Или десяток сегментов одной улицы с дублирующимися тегами только ради запретов поворота...

Komяpa wrote:

А почему бы не провести по трём точкам вей, в котором написать restriction=yes? И запрет опишете, и релейшены не нужны.

Тоже вариант. Только подправить валидаторы чтобы они не ругались на overlapping ways.

Last edited by chnav (2010-10-07 14:41:29)

Eugene120 · 2010-10-07 14:46:11

Откуда такая боязнь дробить?

Announcement

#1 2010-09-21 17:58:43

turn restriction: неудобный стандарт

#2 2010-09-21 18:03:23

Re: turn restriction: неудобный стандарт

#3 2010-09-21 18:03:24

Re: turn restriction: неудобный стандарт

#4 2010-09-21 18:05:44

Re: turn restriction: неудобный стандарт

#5 2010-09-21 18:07:36

Re: turn restriction: неудобный стандарт

#6 2010-09-21 18:13:59

Re: turn restriction: неудобный стандарт

#7 2010-09-21 21:46:27

Re: turn restriction: неудобный стандарт

#8 2010-09-21 21:51:33

Re: turn restriction: неудобный стандарт

#9 2010-09-21 22:02:49

Re: turn restriction: неудобный стандарт

#10 2010-09-21 22:11:28

Re: turn restriction: неудобный стандарт

#11 2010-09-21 22:11:31

Re: turn restriction: неудобный стандарт

#12 2010-09-21 22:22:56

Re: turn restriction: неудобный стандарт

#13 2010-10-07 08:44:29

Re: turn restriction: неудобный стандарт

#14 2010-10-07 08:47:07

Re: turn restriction: неудобный стандарт

#15 2010-10-07 09:18:04

Re: turn restriction: неудобный стандарт

#16 2010-10-07 09:45:41

Re: turn restriction: неудобный стандарт

#17 2010-10-07 13:21:02

Re: turn restriction: неудобный стандарт

#18 2010-10-07 13:52:42

Re: turn restriction: неудобный стандарт

#19 2010-10-07 14:13:15

Re: turn restriction: неудобный стандарт

#20 2010-10-07 14:17:27

Re: turn restriction: неудобный стандарт

#21 2010-10-07 14:29:35

Re: turn restriction: неудобный стандарт

#22 2010-10-07 14:33:33

Re: turn restriction: неудобный стандарт

#23 2010-10-07 14:37:55

Re: turn restriction: неудобный стандарт

#24 2010-10-07 14:38:03

Re: turn restriction: неудобный стандарт

#25 2010-10-07 14:46:11

Re: turn restriction: неудобный стандарт

Board footer