Да, сносить нахрен.
Задачка: почему OSRM не ведет по этому маршруту напрямую, по съезду, а предлагает выписывать кругаля?
http://www.openstreetmap.org/directions?engine=osrm_car&route=55.9053%2C37.4789%3B55.8961%2C37.4838#map=14/55.8953/37.4890
В OSRM debugger эти съезды подсвечены как не участвующие в графе:
http://map.project-osrm.org/debug/#14.41/55.8991/37.4791
А что это там на Библиотечной стоит vehicle=no при этом там нарисована действующая заправка, и еще oneway=no на tertiary зачем-то.
Действительно
Ну вот, зачем-то опять убрали гольф с островка на Бабаевском пруду в Лосином острове, рядом с остальными правками эта была вершиной реализма и полезности.
А объясните мне, пожалуйста, ситуацию со съездами на МКАД.
Вот есть точка http://www.openstreetmap.org/node/3221531726 - тут начинается съезд №9. Вот сам съезд http://www.openstreetmap.org/way/316035971 который от нее начинается.
А нафига вот эта точка http://www.openstreetmap.org/node/995143547 которая обозначена также как первая, но от которой не начинается вообще никакой съезд (это просто точка посреди МКАД)?
Аналогично - для восьмого съезда: http://www.openstreetmap.org/node/3221532675 и http://www.openstreetmap.org/node/995155086 вообще непонятно где. В то же время на http://www.openstreetmap.org/node/995155099 от которой действительно начинается съезд, ничего не обозначено.
Какой-то бардак.
Бардак потому, что съезды были обозначены до реконструкции развязки. За последний год ее полностью перекроили (я ее отрисовывал по ПОД), где теперь какой номер съезда, можно увидеть только на местности (в ПОДе это не указывают)
с точки http://www.openstreetmap.org/node/995143547 теги съезда, конечно, надо удалить
Ну вот мой вопрос был больше по части точек, на которых висит тег съезда, а самого съезда там нет, потому что это не неполная, а ложная информация, способная ввести в заблуждение навигатор, например. То, что теги съезда где-то не висят - не столь катастрофично.
Изменён URL тайлов адресного реестра Москвы:
tms:http://trolleway.nextgis.com/api/component/render/tile?z={z}&x={x}&y={y}&resource=42,45
Похоже уже нет. Случайно обратил внимание, что конвертор (osm2mp для 7 дорог) настроенный для понимания is_in:neighbourhood, уже и как бы не понимает это значение.
В какой то момент ослабил контроль и не знаю на каком этапе это произошло. Была ли мной сделана критичная правка конфига, или в базе OSM новшества? Пока не пойму. Странно что молчат Зеленоградцы, пользователи 7 дорог. Наверно теперь таких нет, но адресный поиск микрорайонов по Зеленограду в моих картах для 7 ways сломан. Будем искать ответ на возникший вопрос - что произошло с микрорайонами Зеленограда?
P.S. если кому то известна причина скрывающаяся в исходных данных - укажите. Нет желания ломать конфиги, убивать время на многочисленные тестирования по чем зря. Мне кажется я совсем недавно лицезрел микрорайоны в поисковой системе 7 ways. Может месяц назад, максимум два.
Уф, кажется нашел причину у себя в конфиге. Всё работает. Полноценная карта для 7 дорог в очередном обновлении.
А кто-нибудь знает, почему некоторые съезды с МКАД обозначены весьма странным образом?
Пример:
Вот собственно точка, съезд с МКАД http://www.openstreetmap.org/node/991778689 - совмещенный 93A и 94 у которого вместо ref=93A;94 установлен ref=93A, 94 (с запятой и пробелом, маппинг под рендер).
По идее, дальше должен идти *_link с соответствующим ref (есть еще конструкции ref:left и ref:right, которые вроде бы использует Mapbox), и всё. И действительно, там начинается http://www.openstreetmap.org/way/23014821 у которого ref=93A, 94 (опять неправильно).
Дальше, где он раздваивается на два съезда, снова стоит (ненужная) точка highway=motorway_junction http://www.openstreetmap.org/node/248133174 , снова с неправильным ref=93A, 94
После раздвоения начинаются, соответственно http://www.openstreetmap.org/way/23014826 и http://www.openstreetmap.org/way/85636708 у которых, как и полагается, установлены индивидуальные ref.
Но вот за каким-то хреном на каждом из них, на небольшом расстоянии от раздвоения, снова установлены точки highway=motorway_junction , каждая со своим ref - http://www.openstreetmap.org/node/1395251430/history/ и http://www.openstreetmap.org/node/1110460852/history/ Я не удивлен тому, что их установила известная сотрудница Спутника a_isaeva. Но бардак устранить нужно.
То есть:
- удалить все дополнительные motorway_junction, не находящиеся в точках действительного съезда с магистралей
- исправить ref в соответствии с правилами оформления списков значений
- добавить ref, соответствующие номерам съездов, на *_link там, где их нет
- опционально - добавить ref:left, ref:right там, где съезды совмещенные.
Я ничего не упустил?
Как всё, однако, запущено с развязками. Нормальная ситуация, когда одна дорога, проходящая под другой, лихо отмечена, как tunnel=yes, хотя на самом деле, это проходящая над ней дорога - bridge=yes, а сама нижняя - всего лишь covered=yes и cutting=yes. Тоннель, по определению - сооружение для транспортных целей в естественной породе. То есть если над дорогой сверху только рукотворные перекрытия, являющиеся полотном для дороги, которая проходит уровнем выше, ни о каком тоннеле речи быть не может. Я понимаю, что в русскоязычной документации какой-то идиот когда-то написал, что тоннель - “это когда длинное”, но это же не причина повторять за ним выдумки?
Если учесть, что точка съезда ставится в начале линка, то есть по сути на МКАД, что из трех веев будет левым, а что правым?
А ставятся ли номера съездов на линк в ref? Это же номер съезда, а не индекс дороги (линка)
О каких конкретно трех веях идет речь?
Номера съездов на линк ставятся. ref - это не обязательно индекс дороги. Для индекса дороги, на которую ведет линк, есть destination:ref.
Номера съездов ставятся на точку, в которой начинается линк.
Писать номер съезда в ref на линке считаю неправильным! Т.к. это именно номер съезда, а не номер дороги (линка). Согласен, что в навигаторе озвучивается красиво.
Я следую той схеме, которую рекомендует и использует Mapbox. Судя по тому, какой бардак творился с этими обозначениями целый год (см. выше), единообразие этой схемы в Москве вообще до меня никого не волновало.
Mapbox рекомендует следующее:
На точку, где начинается ответвление link от магистрали, ставится соответствующий тег junction и его номер (номера, через точку с запятой) в ref. Далее, сами link (в идеале) должны иметь ref, соответствующие номеру съезда, потому что link и есть съезд с одной магистрали на другую, а не только точка, где он начинается. Это также приносит пользу в тех случаях, когда link-и - не одиночные, то есть они дальше раздваиваются или даже имеют возвратный проезд, ведущий назад на магистраль.
В противном случае, обработка данных (например, выборка всех фрагментов одного link) без использования роутера невозможна (то есть даже пространственные запросы не помогают), а это слишком “дорого” для простой операции выборки.
И ответьте, пожалуйста, про “три вея”, хотелось бы знать, о чем вы, а то может я что-то упустил из вида.
Добавлю, что есть, как минимум, две очень похожие конкурирующие схемы, во второй рекомендуется использовать junction:ref для самих link-ов, но я не знаю случаев, чтобы ее кто-то поддерживал, а кроме того, лично я не вижу логики в использовании “особого” ref, то есть junction:ref, так как у него нет отдельной самостоятельной функции - о назначении ref, висящего на link, можно легко судить из сочетания с самим *_link.
В принципе, единственный адекватный метод на данный момент. В любом случае, вам надо объявить благодарность за то, что этот бардак решили разгрести! 
извиняюсь , это я ошибся, первоначально подумав, что речь идет о точке с ref, а не о линии.