К сожалению в текущей реализации 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. При этом полилинии разбивать не надо.
Текущая реализация в ОСМ:
Как описать то же самое без дробления вея:
Может это где-то уже обсуждалось в пропозалах, почему отказались от трех нодов, а приняли текущий стандарт с веями ?
При добавлении нодов ближайший нод (из новых добавленных) к node_via должен взять на себя роль from_node или to_node вместо предыдущего. Конечно это должно быть реализовано автоматически в редакторе, даже диалоговое окно юзеру показывать не надо.
Кстати так будет легче соединять веи, имеющие рестрикшины: после объединения запреты поворотов останутся без изменений.
А чем плохо дробить? Мы же дробим, например, для maxspeed-а и для кусков с плохим surface. Хотя и то и другое можно было бы описать релейшином с двумя точками (start, end).
Отличная идея, хотя в данном случае для однозначности лучше указать way_id+node_start+node_end, тогда можно создавать скоростные профили с любой детальностью. Дробить же веи для этого похоже на вандализм
Сложности с таким дроблением могут привести к тому, что раздробленые улицы мы начнем собирать обратно в рилейшены, например для того чтобы не менять одинаковые атрибуты у десятка веев вместо одного.
А как же перемещение точки? А если вей между точками все же разобьют, например, мостом. (сам себе противоречу: сначала сказал что можно через start/end, а теперь показываю что нельзя … плохо поступил, знаю
Это не плохо и нормально, если обусловлено объективными факторами (surface отличается, или еще какой-то атрибут). Но рилейшены являются надстройкой над примитивами, а получается наоборот - чтобы создать рилейшен “запрет поворота” мы вынуждены дробить примитив. По идее рилейшен должен создаваться на основе тех объектов которые уже есть, без любых других дополнительных условий типа дробления. Это примерно как при написании программы на C мы каждый раз лезли бы в ассемблерный код системных библиотек и правили их под сиюминутные нужды.
Господа, требуется ваша помощь.
Как инициировать обсуждение варианта с тремя точками, описанного в первом посте ?
Я дробить дороги не хочу, рилейшены создаю (пока без загрузки на сервер), но толку от них мало, если они не будут использоваться в конечном формате для навигации. Еще меньше шансов выжить без поддержки такого типа в JOSM, а это уже требует внимания зарубежных коллег.
Куда следует постить свои предложения - в Relation:restriction/Proposals или Relation:restriction/Talk, или вообще связываться с авторами JOSM ? Каковы шансы что на эти страницы вообще кто-то зайдет ?
Спасибо!
Можно ли править Proposed Features по результатам обсуждения (что-то добавить, убавить, переименовать) ? Сомневаюсь что могу всё описать правильно с первого раза
Честно признаюсь, из 2-х редакторов, которыми пользуюсь ни один не называется JOSM
Первоочередным должен быть potlatch, через него все начинают. Надо решить проблему в принципе, а не писать надстройки под конкретный редактор… текущая система наиболее понятна. Единственное что, нужно что бы в роли via мог выступать way или node->way->node.
