Имеющимися средствами НЯК нельзя охватить все случаи, когда нужно указать, что на перекрёстке запрещены какие-либо из манёвров.

И камушек в огород Яндекса: НЯК при отрисовке графа используют, как и фидбэк на самом ЯК, но делают это с огромным запозданием. Уже полгода по разным каналам не могу добиться, чтобы на карте Казани отобразили запрещённые левые повороты на всём Булаке; и это лишь одна из множества необходимых правок в маршрутный граф.

>текущие средства НЯК позволяют организовать развязки практически любой сложности

Вы шутите? Где запреты поворотов? Где ограничения движения по времени суток? Где ограничения в зависимости от вида транспорта?

>судя по Вашему ответу, - не планируется

Я Вам больше скажу: исходя из некоторых пунктов Правил НЯК и некоторых тезисов по результатам обсуждения в Клубе, даже не планирует запланироваться, так как в случае "запланированности" надо менять Правила в расширенном их толковании, чтобы потом переделывать меньше. То есть это не только вопрос функциональности. Ну и конечно с таким перечнем классов дорог нельзя сделать адекватного автороутинга (авто - автоматический, а не автомобильный).

>если будет навигация по НЯК, то будет ли учет пробок в такой навигации?

Пробка характеризуется привязкой, например, идентификатором участка дороги (по координате принадлежащей участку дороги, сделать это нельзя). Поэтому если есть две и более разные системы идентификации дорог в графе, либо работает одна, либо данные должны дублироваться в той части, в которой идентификация участков дорог в графе различна. Ровно такая же проблема например у Навитела, если пользоваться сильно старыми официальными атласами.

>потребует отдельных технических переделок, не связанных с самой навигацией по НЯК

Безусловно потребует. С точки зрения теории, пробки ЯК+НЯК как и проблемы навитела с пробками по сильно разным версиям атласов - это пример реализации атрибутики над версионным графом. Сделано сбоку может быть, но скажем так, сильно неоптимально, как если планировать это сразу.

Запрет поворот можно сделать правильной организацией развязки текущими средствами.

Про время не учел, согласен, но это входит в  "почти все", т.к., в рамках страны, таких дорог не так уж и много - только в ряде мегаполисов и то, не на каждом шагу.

А что? ЯК учитывает вид транспорта? Где я могу ему указать, что еду на грузовике, а не легковушке, и что на меня будут действовать соответсвующие ограничения?

"Планируется" и "планируется запланировать" одно и тоже. Какая разница, что включается в это "планировать" и сколько в этом этапов? Вот вообще не принципиально. Принципиален только результат.

Про идентификаторы, честно говоря, не до конца понял, как организовано. Потому уточню: в чем проблема сделать метакласс и соотвествующий объект для этих участков дорог (даже если в одной из систем ЯК и НЯК этот участок "сборный" из более мелких), идентификатор которого один общий, и привязать пробки к метаобъекту, а не участку дорог в одной из систем? К слову, именно об этом я говорил, упомянув, что не знаю, как сделано сейчас, и допускаю, что тоже нужны будут переделки в организации Пробок. Насколько это трудоемко, целесообразно и т.п. - это ответ на вопрос "планируется ли". А этот ответ уже был дан.

Ну, собственно, ничто не вечно, и реорганизация, даже полная, существующих систем - вопрос времени, не более. И вопрос был "планируется ли", что в данном ключе можно трактовать как: "Не назрело ли?" Опять же, ответ уже был дан.

>"Планируется" и "планируется запланировать" одно и тоже.

Никак нет. Планируется запланировать - значит ещё не запланировано.

>в чем проблема сделать метакласс и соотвествующий объект

А при чём тут метаклассы и объекты, если речь идёт исключительно о реляционных отношениях поверх версионного графа? Там может быть вообще никаких классов нет.

>ЯК учитывает вид транспорта?

Понятия не имею, я не пользуюсь янавигатором. Но приличная навигация обязана это делать. Как минимум, критически важны различия между грузовиком, пешеходом, такси и обычной легковушкой.

Суть в том, чтобы на НЯК нужны данные по роутингу от самой НЯК, которые можно править и уточнять, а не от сторонней системы. Ну и вообще всяческая интеграции с остальными сервисами и приложениями Яндекса.

>Роутинг на НЯК очень легко сделать самому

>Он уже строит маршрут по дорожкам, которые я неделю назад рисовал

Кроме НЯК есть другая крайность: OSM и его выгрузки для garmin-ов и прочих navitel-ов. Собственно, "цена вопроса" очевидна:

а) недостаток классификации дорог;

б) надостаток функциональности НЯК;

в) массовый контрибьютор НЯК не в состоянии аккуратно всё заполнять и тратить на это на порядок больше времени;

г) администрация сервиса навряд ли готова повысить ценз для вхождения в сервис для целей рисования графа роутинга и отсечь 90% хомяков, хотя как вариант, можно было бы блокировать для изменения участки карты и там специально обученными юзерами формировать данные для роутового графа (но видимо пока проще брать граф с ЯК и скрещать его с НЯК).

+1

Хочется, чтобы мобильные яндекс-пробки корректнее функционировали. даже нет особой разницы - ЯК или НЯК, главное, чтобы пользовательские правки или пользовательские сообщения об ошибке быстрее или хотя бы регулярнее реализовывали и на дорожном графе.