Как Вы понимаете, в общем случае это не работает. Кратчайший из нарисованных маршрутов имеет полное право вылезти за скачанный прямоугольник. (это так, к слову)
Это не то что в общем, это в половине случаев не работает.
Реки и ж/д никто не отменял 
Т.е. нужен, как минимум, материк? 
Ivan Komarov, нужен связный_граф
Много знаете устройств на Maemo и Openmoko?
На чем писать - выбор несомненно автора, однако будет досадно, если хороший проект не будет популярен из-за плохой поддержки устройств.
Вообще говоря, программы на .Net, написанные для WM, можно свободно пускать на семействе Windows NT.
На Windows XP, например :3
Все равно, дотнет не ну… ну вы понели.
Ой, а и правда. 
Спасибо.
Кто его может дать?
Давайте не будем уходить от темы. Я знаю С# и хочу попробовать пописать под WM. Всё остальное сейчас не важно.
Real 3L0, никто. самому делать надо будет
Ну сам так сам.
Значит пока начну с тайтлов.
Постарайся сразу заложить в систему заглушки под роутинг, приём с gps-порта и прочее сейчас отсутствующее, но подразумеваемое, что бы потом по живому не резать. (и костыли не ставить). И как все эти данные будут от процесса к процессу пу(к)тешествовать. (Оно, скажешь, очевидно, но на всякий случай решил влезть))).
опять шарп…идея хорошая, но ИМХО лучше cpp и Qt)
Да, кстати, один лишь граф дорого выдрать мне кажется вполне можно… не будет кучи домов, рек, границ и т.д.
Отрисовывать простые линии, которые показывают маршрут, поверх обычных тайлов - это тоже не напряжно… возможно не такой уж и большой объем данных придется выводить.
Нужно экспериментировать.
желаю автору удачи!)
Не видел ни одного более-менее сложного проекта получившегося с первого раза без костылей. Нужно хоть немного набить шишек в новой предметной области, чтобы сделать правильную архитектуру. Так что забудьте, прототип - на выброс 
У мну руки уже давно чешутся наваять на Qt хотя-бы виджет для векторных карт. А роутинг, да чтобы со сбором и учетом статистики скорости - вообще мечта)
В общем, в проекте на Qt я готов участвовать )
А почему нельзя роутинговый граф тоже разбить на куски и хранить/загружать их по-отдельности? И для построения маршрута из точки А в точку Б загружать нужные области, которые лежат между этими точками + ближайшие соседние.
Со мной та же фигня
Потому, что в роутинговом графе не хранится географическая информация. Получается замкнутый круг - чтобы загрузить нужные области, нужно знать маршрут, а чтобы построить маршрут, нужны области.
Но ведь строиться этот граф всё-равно будет по данным OSM и там то эти данные есть. Моя идея такая (это я вообще для себя придумал для генерации 3D тайлов, но по идее и для графов технология должна подойти )
- Пользователь указывает точку А и Б
- Определяем, какие области нам нужны для построения пути.
- Запрашиваем все области
а) Смотрим, не лежит ли данная область в КЭШе программы, если не лежит то б) иначе пп.4
б) Проверяем не лежит ли данная область на НАШЕМ сервере, если не лежит, то в) иначе пп.4
в) Раз мы тут, значит граф для данной области ещё не построен. У нас есть ограничивающий область прямоугольник. Сделаем запрос данных по области (через xapi или ещё как. Можно даже из нескольких источников) и получим векторные данные области. По этим данным сформируем роутинговый граф для нашей области и сохраним его на НАШЕМ сервере, чтобы в дальнейшем другие пользователи могли его оттуда скачать, не затрачивая время на генерацию и сохраняем в КЭШ программы, чтобы повторно не закачивать с сервера. - Берем все графы загруженных областей и строим по ним маршрут.
Вот так я это себе представляю. Само собой я не учитываю сложность при объединении областей графов + возможно другие трудности, которые я пока не вижу.
Кстати, в Qt довольна неплохая поддержка SVG. Если данные OSM конвертить в SVG, а его уже отрисовывать штатными средствами, никакого виджета ваять не потребуется
Спасибо, но С++ я забыл как страшный сон.