Я бы сказал по другому: “из данных OSM принципиально невозможно сделать универсальную карту для текущих программ навигации, поскольку их авторы ориентируются исключительно на автомобильное применение, поддерживая пешеходов по остаточному принципу”.
Что и понятно - основные деньги то от автомобилистов идут.
Sergey Astakhov, нет, правильнее будет “из данных OSM принципиально невозможно сделать универсальную карту”, точка 
И дело не в текущих программах (хотя других всё равно нет), а в склонении участников осм представлять данные в таком виде, которые для навигации принципиально непригодны. На пешеходных данных это просто особенно заметно.
//На пешеходных данных это просто особенно заметно.
А мне кажется что идея построить пешеходный рутинг по аналогии с автомобильным, на базе дорожного графа, изначально порочна. Маршрут для пешехода должен прокладываться просто поперек карты, если нет препятствий - заборов, домов, и тех же дорог. Если есть препятствия - в обход (как в компьютерных играх). А пешеходная дорожка - это просто некий предпочитаемый путь, подсказка. В таком случае пешеходный мостик/подземный переход и не будет должен ни к чему пристыковаться.
Я понимаю конечно, что до реализации такого рутинга как до неба - семь верст, и все лесом. 
А я считаю, что возможно. Многоточие. 
Нет, дело именно в программах. Почему они притягиваются к пешеходным дорожкам в автомобильном режиме? Тоже участники OSM виноваты? Или дело таки в разработчиках, которые не хотят делать фильтрацию графа в зависимости от режима? Почему я в своей системе могу сделать такую фильтрацию, а они нет?
А то, что участники не хотят подстраиваться под ограничения конкретных навигаторов - это собсно изначальный выбор проекта: не рисовать под рендерер/конвертер/навигатор. Вот тут действительно точка.
100% согласен. Главная проблема тут - скорость работы алгоритма. Я для нашего портала хотел сделать подобный роутинг, но, т.к. я щас занят на другом направлении, а роутингом пока занимается другой разработчик, там используется вариант по старинке, с графом. Но я не оставляю надежды реализовать свои идеи.
Zkir, не совсем так, обычное пешеходное движение (а не слоняние) вполне можно представить графом. А основная проблема в том, что для этого графом нужно представлять именно стандартное движение, а не всё, на что можно поставить ногу. В осме же большинство склоняется ко второму варианту.
С авто-роутингом на самом деле те же проблемы, только там их (пока) удаётся не выпускать выше уровня сервисов. Поэтому выкинув сервисы (опять же - пока) можно получить более-менее вменяемый роутинг.
Cкорее всего уже офф пошел в теме, но:
Ну если все это где можно поставить ногу нормально прорисовано и соединено, конечно не кучу векторов на одном квадратном метре, а именно дорожки и народные тропы и проставлены акцес на воротах, то в “пешеходном” режиме в Garmin ведет на ура обходя все эти частные дома и школы с заборами, если это конечно нужно кому, но отсутствие в Garmin прямого запрета, а только нежелательности, портит автороутинг.
Офф: справедливости ради сервисы в Garmin скорее полезны чем вредны, некоторые случаи срезания по дворам (сервисам) лечатся понижением maxspeed, правильным углом, дестинейшинм, но есть “загадочные” места, где ни чем не лечится, тут если только вводить костыль в виде предложенного тега “полезности” для конкретного прибора 
Мое ИМХО.
По сервисам: сервисы нужны не для прокладки транзитного маршрута, но для правильного подъезда к дому. В частности если дом в середине квартала, то как к нему проехать.
По тротуарам: я считаю что в ОСМ нужно рисовать дороги как они определены в ПДД
То есть тротуар отделенный зеленой полосой - отдельная тропинка, тротуар непосредственно вдоль проезжей части - часть дороги.
При этом надо добавлять теги по наличию тротуаров, соответственную поддержку в конвертеры и рендеры и т.д. Здесь надо делать большую работу, включая проработку деталей, пропозишн в вики и т.д. Здесь все зависит от того, какое количество людей разделяет мою точку зрения, особо имея ввиду разработчиков конвертеров.
Обсуждение в очередной раз свелось к сферическим навигаторам в вакууме
//обычное пешеходное движение (а не слоняние) вполне можно представить графом.
Понятно что можно, вопрос нужно ли этот граф рисовать в OSM. Этот граф в намного большей степени абстракция, чем автомобильный, при том что такого объекта как дорога (см. выше) мы до сих пор не рисуем.
dimuzz,
Кажется нужно поправить navitel-rt.yml. Нужно в секцию load добавить -output-polish, если я ничего не путаю. Может, ещё что-то поменять нужно.
Сдалал. Также сделал правильную отдачу 7z архивов, добавил в список сборку архива России целиком и конвертацию Красноярского края и Якутии.
Вау… ни одного региона с ошибкой.
будет после обновления
Поправил. Чисто роутинговая конфигурация требует измененного файла конфигурации вывода в mp (output-polish-rt.yml). В роутинговом mp оставлен только один уровень Level0=24, соответственно, в mp не попадают level_l и level_h. Также убирается вся адресная информация (Label остается для визуального контроля).
(At revision: 109)
Уважаемый Fortress, на старом ресурсе http://osm.fmesh.org/navitel.html , где карты не обнавляются, очень желательно сделать редирект или ссылку на новый http://navitel.osm.rambler.ru/
А то старый ресурс народ уже знает и смотрит туда.
Сам две недели понять не мог почему нет обновлений, пока в форум не заглянул.
И можно ли опубликовать скрипты конвертации и обрезки по регионам?
Чтобы можно было самим корректно сконвертировать и обрезать нужный регион и чтобы он был небыло разрывов и наложений с соседними регионами.
Это сайт Ивана Комарова. Нужно к нему обращаться.
Примерно так: http://pastebin.com/nViX1ySN (%1 - имя региона с гис-лаб)
add: упс, опоздал… ну на самом деле скрипты у всех отличаются, кому как удобнее…
Обратил внимание, что osm2mp конвертер добавляет в mp файл коментарии с встречающимися ошибками. Я думаю было бы полезно, генерировать постпроцесингом еще один файл с ошибками/предупреждениями. Правда подходить к этим ошибкам нужно выборочно, не все что является ошибкой для конвертера - ошибка для OSMа.