А почему нельзя роутинговый граф тоже разбить на куски и хранить/загружать их по-отдельности? И для построения маршрута из точки А в точку Б загружать нужные области, которые лежат между этими точками + ближайшие соседние.
Со мной та же фигня 
Потому, что в роутинговом графе не хранится географическая информация. Получается замкнутый круг - чтобы загрузить нужные области, нужно знать маршрут, а чтобы построить маршрут, нужны области.
Но ведь строиться этот граф всё-равно будет по данным OSM и там то эти данные есть. Моя идея такая (это я вообще для себя придумал для генерации 3D тайлов, но по идее и для графов технология должна подойти )
- Пользователь указывает точку А и Б
- Определяем, какие области нам нужны для построения пути.
- Запрашиваем все области
а) Смотрим, не лежит ли данная область в КЭШе программы, если не лежит то б) иначе пп.4
б) Проверяем не лежит ли данная область на НАШЕМ сервере, если не лежит, то в) иначе пп.4
в) Раз мы тут, значит граф для данной области ещё не построен. У нас есть ограничивающий область прямоугольник. Сделаем запрос данных по области (через xapi или ещё как. Можно даже из нескольких источников) и получим векторные данные области. По этим данным сформируем роутинговый граф для нашей области и сохраним его на НАШЕМ сервере, чтобы в дальнейшем другие пользователи могли его оттуда скачать, не затрачивая время на генерацию и сохраняем в КЭШ программы, чтобы повторно не закачивать с сервера. - Берем все графы загруженных областей и строим по ним маршрут.
Вот так я это себе представляю. Само собой я не учитываю сложность при объединении областей графов + возможно другие трудности, которые я пока не вижу.
Кстати, в Qt довольна неплохая поддержка SVG. Если данные OSM конвертить в SVG, а его уже отрисовывать штатными средствами, никакого виджета ваять не потребуется
Спасибо, но С++ я забыл как страшный сон.
asaw, x10kHz давайте объединимся и С++ вариант стартуем
PyQt, RubyQt не удовлетворит?
Ну SVG, возможно, подошел бы как способ реализации отображения карты. Однако, ИМХО сабж весьма сложный и со сложностью нужно бороться. То есть, как минимум, разделять интерфейсы и реализацию. В качестве “виджета” я вижу связку типа Model – View – Controller, в которой главное - модель данных. И тут уже, по-моему, SVG совсем не подходит в качестве модели данных. Да и как способ отображения, по-моему, SVG - слишком уж медленно и не слишком элегантно (дополнительное преобразование данных из модели в XML, затем парсинг XML внутри QSvgWidget - получается ещё один лишний “тяжелый” интерфейс).
Давайте. Для начала хорошо бы более-менее окончательно определиться с целями и функциональными/нефункциональными требованиями.
реализацию рендерера в merkaartor не смотрели?
довольно шустрый. кастомайзится стилями
А смысл?
Я немного (мне хватает) знаю шарп. Шарп меня всем устраивает. Для моей текущей цели он подходит.
Но вам желаю удачи - она вам очень сильно понадобится - за последнее время тут много проектов старотовало, но я ни одного не видел, который продвинулся дальше этого форумал.
Кроссплатформенность. Завязываясь на технологии Microsoft, получим 9001-ю софтину Windows-only.
Это меня сейчас меньше всего беспокоит. 
Зато это очень беспокоит нас. Хотя, судя по всему, вы просто хотите попрактиковаться в программировании. :3
Я когда-то тоже кодил на шарпе и считал его мега крутым языком и вообще платформой.
Помнится мне нравилось там быстро формы делать, всякие модные фитчи студии в этом очень помогали… кодить удобно)
Но политика майкрософта и запуск этого IL-кода на виртуальной машине мне очень не нравились. Скорость выполнения нативного кода + возможность контролировать все руками + столь же удобный кодинг при использовании сторонних либ типа буста и Qt + полная кроссплатформенность… ИМХО все это переплевывает все фишки связки шарпа+студия и оставляет её далеко позади)) ИМХО от архитектуры приложения многое зависит, можно и на шарпе написать нормально, и на можно С++ написать тормознутую хрень, но в целом нативный (не для .NET) С++ значительно быстрее.
На мой взгляд шарпом нужно просто “переболеть”))
На самом деле скорость выполнения такая же, как и у кода C++.
Другое дело скорость запуска, когда должен сначала загрузиться фреймворк. Это особенно важно для КПК. Хотя там и compact framework. :3
Обожаю тезисы, начинающиеся словами “на самом деле” 
Нужно не путать назначение этого средства программирования… .NET это аналог-конкурент Java, а главная ниша продуктов написаных под виртуальные машины это монстроподобные энтерпрайз-приложения. … никогда бы раньше не подумал, пока не столкнулся с банковским софтом…раньше тоже казалось что весь серьёзный софт пишут на C и Cpp …ан нет…
И нет идеального языка, к которому надо придти “переболев” неправильными
Я например, волею судьбы, выучил язык 1С 7.7 … у меня после этого кардинально мнение поменялось в отношении его (а ведь очень многие его считают бейсиком на русском языке)
Для каждой задачи есть свой инструмент… и если C++ выбирать только потому что “он быстрее работает”…то это просто странно.
А с Вашей точки зрения для данной задачи какой инструмент стоит выбрать?