При конвертивании из OSM сейчас не поддерживается, на сколько я знаю, разделение по полосам. Честно, вообще ни разу не видел даже навигатора, который бы говорил о том какую полосу нужно занять для маневра, поэтому:
Сейчас важнее охват сделать основной, уточнять можно будет потом все знаки движения по полосам. Сейчас улицы показывайте одной линией если проезжая часть одна и нет таких разделителей, которые нельзя переехать (трамваи, клумбы).
Знаки движения по полосам запрещают повороты и развороты.
Честно говоря слабо понял организацию движения на перекрестке, но самое важное, что я вынес:
Первомайский при движении с запада на восток до Мелентьевой разделен, после этого перекрестка уходит на на северо-восток где он уже не разделен. На перекрестке можно поехать прямо - это двухсторонняя улица Шотмана. При движении с Мелентьевой можно повернуть только направо на Первомайский. Все это я нарисовал, можете посмотреть и поправить.
У вас были ошибки - Мелентьевая и Первомайский не имели общих точек, они просто были 2 очень рядом. На вид нормально, но для роутинга непригодно. Почему Первомайский меняется с primary на resentail? Почему одна часть первомайского не имеет названия?
Адаптировать под навигацию проезд регулируемых перекрёстков.
Минимизировать количество необходимых точек светофоров в области таких перекрёстков.
Дополнительно можно (и нужно) проставлять время работы светофора (по классической схеме opening_hours «дни-часы»)
В результате не появляется нагромождение изображений светофоров на карте. Отдельными точками имеет смысл обозначать дополнительные светофоры по траектории следования (отдельная стоп-линия и всё такое по ПДД) и связывать их с соответствующими отрезками дороги.
Также появляется конкретная информация для определённых участков, проезд по которым связан со светофором.
Устраняется неоднозначность для учёта времени проезда перекрёстка и появляется возможность точнее подсчитать это время для каждого направления.
*Отрезки A, B, C формируются как и для маршрутов общественного транспорта: последовательным добавлением участков пути. Каждому сегменту присваивается роль direction. Первый и последний сегмент выбираются таким образом, чтобы исключалась двоякость интерпретации варианта проезда.
Кстати, побочно такая схема будет показывать и разрешённые пути проезда перекрёстка.
*Предлагаемая схема не требует каких-либо изменений в существующей «топологии» отрисовки перекрёстков.
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 веями => получается каша).
Светофорное отношение — основа, каркас. Базово он предоставит «минимальный пакет плюшек», о которых говорилось (сокращение расплодившихся липовых светофоров, учёт при навигации). Далее — есть возможность обвешивать его более подробными деталями в зависимости от задач и условий (delay:conditional, opening_hours и т. д.)
Появится возможность в первом-втором (для особо сложных случаев) приближении учитывать много полезной информации, а также убрать лишнюю/некорректную.
Для среднестатистических светофоров при должном тегировании информация будет исчерпывающей.
За актуальностью будут следить активные участники, другого просто не дано (как и для всей базы OSM, собственно). Да, заметку новичок/прохожий не поставит, а это и не нужно.
Все эти задачи по превращению OSM в супер информационный проект в том состоянии в котором находится OSM сейчас никогда не будут реализованы… Следить можно с большой степенью точности в отдельном малом населенном пункте, если есть кому конечно или в отдельном небольшом райончике города. А весь остальной город? А варварские правки которые напрочь уничтожают одним движением все то что нарисовано-внесено непосильным трудом ? А информация о тех же режимах светофоров, которая может измениться в любой момент и это приведет тут же к инерционной не валидности данных? А когда все это начнет поддерживаться софтом хоть каким нибудь? А новички которые откроют всю эту кашу редактирования - пошлют нафиг весь этот OSM - ну так им это и действительно в таком виде будет не нужно…И в итоге будет как и писал один уважаемый пользователь - все эти данные будут только для тех кто хоть как то сможет их обрабатывать в сыром виде, остальные их никогда не увидят и не узнают про то что там что то куда то внесено…
Не путайте тег дорожного знака запрета, и отношения запрета маневра.
В ОСМ первый лишь для вывода картинки годится, а реально запрещает отношение запрета, который может возникать и от знаков для все дороги и от знаков/разметки по полосам, осевой разметки и от еще чего-нибудь.
