Я конечно не автомобилист, но что-то мне подсказывает, что разрыв в двойной сплошной служит не для разворота, а для поворота налево, на примыкающую дорогу… 
Мне такие развороты устраивал GpsMapEdit, в стиле таксиста когда я маршрутизацию у себя тестировал.
? ??? ??? ??? ??? ??? ???, ??? ??? ??? ???, ??? ??? ? ??? ???, ?? ?? ??? ??? ? ??? ???, ??? ??? ?? ??? ?? ???, ? ??? ???, ??? ?? ??? ??? ? ??? ? ??? ???, ? ???. ??? ??? ??? ??? «??? ??? ???». ?? ??? ? ???. ??? ??? ??? ??? — ??? ??? ? ??? ???, ? ?? ??? ??? ??? ???.
??? ??? ??? ??? ??? ??? ??? — ??? ??? ??? ?? ??? ???, ??? ??? ?? ???, ??? ??? ?? ??? ???, ?? ??? ??? ??? ??? ??? ??? ?? ??? ???, ??? ??? ??? ??? ??? ???-???.
У нас в городе кажется ни одного такого места нет, официального
А если поставить точку на дороге, включить ее как via ограничения поворотов, и запупенить разрешение поворота налево, выбрав в качестве from и to один и тот же предшествующий точке отрезок дороги? %)
Нет… это какая-то ересь на ночь глядя Я не пойму, когда эти развороты могут понадобится при прокладывании маршрута.
А, дошло. Надо изначально на дороге запретить все левые повороты, реально запрещенные. И тогда это будет иметь смысл.
Но если на всех сочленениях левый разрешен, то зачем тогда этот, добавочный, разворот посреди дороги? Он не будет востребован при прокладке маршрута.
Судя по всему, обычный маршрутизатор не имеет представления, что такое левый, правый поворот, разворот, а просто смотрит на члены from, to и restriction=no_* или restriction=only_*, вот и всё. То есть если хочешь запретить все левые повороты, придётся запрещать каждый поворот индивидуально и никак иначе.
Virasio, написали вы, конечно, много, но:
- При конвертивании из OSM сейчас не поддерживается, на сколько я знаю, разделение по полосам. Честно, вообще ни разу не видел даже навигатора, который бы говорил о том какую полосу нужно занять для маневра, поэтому:
- Сейчас важнее охват сделать основной, уточнять можно будет потом все знаки движения по полосам. Сейчас улицы показывайте одной линией если проезжая часть одна и нет таких разделителей, которые нельзя переехать (трамваи, клумбы).
- Знаки движения по полосам запрещают повороты и развороты.
- Честно говоря слабо понял организацию движения на перекрестке, но самое важное, что я вынес:
Первомайский при движении с запада на восток до Мелентьевой разделен, после этого перекрестка уходит на на северо-восток где он уже не разделен. На перекрестке можно поехать прямо - это двухсторонняя улица Шотмана. При движении с Мелентьевой можно повернуть только направо на Первомайский. Все это я нарисовал, можете посмотреть и поправить. - У вас были ошибки - Мелентьевая и Первомайский не имели общих точек, они просто были 2 очень рядом. На вид нормально, но для роутинга непригодно. Почему Первомайский меняется с primary на resentail? Почему одна часть первомайского не имеет названия?
Цели предложения:
- Адаптировать под навигацию проезд регулируемых перекрёстков.
- Минимизировать количество необходимых точек светофоров в области таких перекрёстков.
Дополнительно можно (и нужно) проставлять время работы светофора (по классической схеме opening_hours «дни-часы»)
В результате не появляется нагромождение изображений светофоров на карте. Отдельными точками имеет смысл обозначать дополнительные светофоры по траектории следования (отдельная стоп-линия и всё такое по ПДД) и связывать их с соответствующими отрезками дороги.
Также появляется конкретная информация для определённых участков, проезд по которым связан со светофором.
Устраняется неоднозначность для учёта времени проезда перекрёстка и появляется возможность точнее подсчитать это время для каждого направления.
*Отрезки A, B, C формируются как и для маршрутов общественного транспорта: последовательным добавлением участков пути. Каждому сегменту присваивается роль direction. Первый и последний сегмент выбираются таким образом, чтобы исключалась двоякость интерпретации варианта проезда.
Кстати, побочно такая схема будет показывать и разрешённые пути проезда перекрёстка.
*Предлагаемая схема не требует каких-либо изменений в существующей «топологии» отрисовки перекрёстков.
Где само предложение то ?
Proposal не существует)
Суть изложена здесь. Набор простейших отношений с минимумом тегов на пересечении дорог (в примере их получится 12).
delay=90 - на сложные перекрёстки (которых ради всё и задумывается) не катит, по крайней мере, в реалиях Москвы, Московской области, Ярославля, Иваново, Костромы, Питера, Твери, Владивостока и Уссурийска. Ну, это с ходу что вспомнилось. Во всех этих локациях есть N-ное количество светофоров, где для разных направлений разное время красного/зелёного. Либо, если эта “задержка” - подразумевается “цикл работы”, то с натяжкой может прокатить, но, опять же, глобально - есть много светофоров “по требованию” (не только для пешеходов, а на датчиках плотности потока), которые этот самый “цикл” для основного направления могут увеличивать в 3-5 раз, т.е. вместо 80+17 (зелёный+красный) могут делать до 399+20 сек, например.
Я не просто так упомянул о 12 отдельных отношениях для перекрёстка из примера.
4 потока с максимально возможным набором поворотов - 3 штуки на каждый. Соответственно «delay=90» - это время красного сигнала для поворота налево (если смотреть картинку).
Вряд ли они устанавливаются на перекрёстках. Их можно учитывать, разве что, вероятностно-статистическим методом каким-нибудь. Но к теме они не относятся (по причине отсутствия на перекрёстках).
Но, есть перекрёстки, где в зависимости от времени суток и дня недели (за праздники не скажу) меняются интервалы, т.е. утром “в город”, вечером “из города” потоки по будням направляют - это стрелок “налево” касается, примыкающих к “вылетным” магистралям и “зелёной волны” на самой магистрали.
Переменные интервалы требуют более гибкого тегирования. Например, по схеме delay:conditional=120 @ (06:00-20:00); 100 @ (22:00-06:00) и т.п.
Тогда отпадает и необходимость в opening_hours.
Для пешеходов можно delay:conditional ставить просто на footway=crossing. А если там светофор button_operated=yes, то в качестве значения указывать время, проходящее с момента нажатия кнопки до включения зелёного.
Мне кажется что ничего из этого не получится, да и в принципе пока и без этой информации обходятся неплохо все. Заполнять такое никто не будет, ибо результата от этого можно и вообще не дождаться… Да и сложно это - куча релейшенов, непонятно какие значения, причем действительно нет никаких статических данных - по нынешним временам у современных светофоров можгут быть абсолютно любые значения для их работы, контролируемые из единого центра(ов)…
не в России. В Москве на каждом светофоре стоят контроллеры, программируемые на месте.
Так и есть, но кому-то понравится и он не сможет обходиться)
Ведь проще, чем даже поворотные запреты. А значения вполне конкретные - по таймеру на светофоре или измеренные секундомером. Да, обеспечить сказочную актуальность и аптекарскую точность не получится, но это гораздо точнее и красивее (в плане рендеринга) того, что есть сейчас. Даже без информации о простое на светофоре такие relation будут хорошо показывать регулируемость перекрёстков.
Значит так оно и уйдёт в небытие тихим сапом.
Я был в ЦОДД, там на карте Москвы отображаются все светофоры и текущий режим (т.е. “Цвет”). При клике на нём, можно задать параметры. Не знаю на сколько это рабоче и какой охват у этой системы, но имеет место быть 
Время простоя на светофоре - действительно, слишком непостоянный параметр. А вот объединить точки traffic_signal=yes в отношение светофорного поста - технически не такая сложная задача. Таким образом, по крайне мере, можно будет равнозначно учитывать поворот направо (на пути “поймана” 1 точка светофора) и разворот (“ловит” по 3-4 точки часто). Да и чисто логически, порой, глядя на карту, хочется видеть там как отдельную poi именно светофорный пост, а не пересечения проезжих частей (а дороги у нас рисуют где-то одним, где-то 2 веями => получается каша).
Совершенно согласен. Поэтому и рисовал тут стрелочки-кружочки