К turnlanes одна из серьезных претензий: он сложен.
Если за основу взять формат Прогорода, возможен значительно более простой подход.
А именно, для дороги указывать только значки, с какой полосы как можно повернуть - налево, прямо и т.д. (на какой именно участок дороги повернуть, не указывать). В таком случае в исходных данных немного другая информация, чем в случае turnlanes, но результат в подавляющем большинстве случаев тот же.
Для двунаправленной дороги каждый конец описывается отдельно.
Полосы будем считать слева направо, т.е. от осевой линии дороги (которая разделяет разные направления движения), если она есть. Для каждой полосы указываем знак, как можно поворачивать. Дополнительные полосы учитываются! - ведь знаки на них тоже есть.
В OSM это все можно закодировать с помощью одного дополнительного тега для линии, например, так:
laneinfo:end=ls;s;s;r;
Т.е. 4 полосы: прямо или налево; прямо; прямо; направо. Использованы буквы, чтобы проще запомнить:
прямо - s - Straight
налево - l - Left
направо - r - Right
разворот - u- U-turn
левее - e -slightly lEft
правее - i- slightly rIght
Некоторые знаки получаются комбинированием букв, например, ls - прямо или налево. Эту таблиц можно расширить и до обозначений, применяемых в других странах (крутой поворот направо и т.д.). Левый поворот уже подразумевает разворот и его специально указывать не нужно. Например, писать “lsu” нужно лишь в случае, если в этом месте для данной полосы в реальности висит именно такой знак с тремя расходящимися стрелками - прямо, налево и на разворот.
Число полос понятно из записи, :begin или :end - это уточнение для двухсторонний дороги, для односторонней тег - просто laneinfo.
Если далее идет уменьшение числа полос, то дорогу стоит в этом месте разорвать и указать сужение с помощью e, например, сужение с трех полос до двух:
laneinfo:end=s;s;e
Некоторый минус такого подхода в том, что направление цифровки дороги теоретически можно поменять, тогда надо не забывать и laneinfo:begin->laneinfo:end и наоборот.
(Если не нравится :begin и :end, для laneinfo можно ввести отношение с тегами, ссылающимися на геометрию явно:
relation=laneifno
members:
way=2345642361
node=89012345
tags:
laneifno=ls;s;s;r;
) Однако отношение все же сложнее одного тега. 
В чем принципиальное различие такого подхода по сравнению с turnlanes, помимо сложности формата? Дело в том, что, имея только общий граф дорог, автоматически не всегда (особенно если перекресток сложный и граф для него составлен “плохо”) можно однозначно сопоставить знак и дорогу, на которую надо повернуть. Например, если поворот идет под 45гр - это “направо” или “правее”? В случае мы применения laneinfo бы поставили знак, который реально использован на месте, а в случае turnlanes вычислили бы, но, возможно, он был бы оказался другим. Другой вариант: граф на перекрестке нарисован так, что поворот с первой полосы налево идет через небольшой участок прямо. В случае turnlanes этот участок ушел бы в via, и to можно было бы уже указать участок после поворота. Тогда, действительно, загорится только стрелка влево на первой полосе. В случае же laneinfo можно и “не догадаться”, что при подъезде к перекрестку нужно зажечь только стрелку на первой полосе влево. Т.е. для каких-то случаев лучше может быть laneinfo, для каких-то turnlanes. Для laneinfo стрелки всегда правильные, но иногда, мы можем их “не понять”, для turnlanes движение соответствует стреклам, но они могут не соотвествовать реальным знакам. Вывод: граф движения на сложных перекрестках нужно составлять попроще, и так, чтобы избежать подобных разночтений.
Впрочем, не стоит пугаться, все эти тонкости проявятся только на крайне незначительном числе случаев.
В связи с последним примером следует считать, что laneifno дает только вспомогательную информацию, используемую для рисовки стрелочек и отображения на какую полосу надо перестраиваться при подъезде к перекрестку, но никак не описывает граф маршрутизации, то есть маршрутизацию надо по-прежнему указывать рестрикшенами запретов поворотов, поскольку в них явно указаны way, куда ехать нельзя.
Кстати, использовать обычные рестрикшены запретов поворотов имеет смысл также и в случае turnlanes, чтобы маршрутизация была правильная для программ, не использующих turnlanes.
В конвертере поддержу любой вариант (а может быть и несколько - такой, turnlanes, что-то еще), однако займусь этим примерно через три недели, не ранее. За это время хорошо бы придти к консенсусу. Хотелось бы, конечно, один формат.
Спасибо, что вынесли в отдельную ветку -