Немного программёрской практики. Программа навигатор для КПК

Давайте не будем уходить от темы. Я знаю С# и хочу попробовать пописать под WM. Всё остальное сейчас не важно.

Real 3L0, никто. самому делать надо будет :slight_smile:

Ну сам так сам. :slight_smile:
Значит пока начну с тайтлов.

Постарайся сразу заложить в систему заглушки под роутинг, приём с gps-порта и прочее сейчас отсутствующее, но подразумеваемое, что бы потом по живому не резать. (и костыли не ставить). И как все эти данные будут от процесса к процессу пу(к)тешествовать. (Оно, скажешь, очевидно, но на всякий случай решил влезть))).

опять шарп…идея хорошая, но ИМХО лучше cpp и Qt)
Да, кстати, один лишь граф дорого выдрать мне кажется вполне можно… не будет кучи домов, рек, границ и т.д.
Отрисовывать простые линии, которые показывают маршрут, поверх обычных тайлов - это тоже не напряжно… возможно не такой уж и большой объем данных придется выводить.
Нужно экспериментировать.

желаю автору удачи!)

Не видел ни одного более-менее сложного проекта получившегося с первого раза без костылей. Нужно хоть немного набить шишек в новой предметной области, чтобы сделать правильную архитектуру. Так что забудьте, прототип - на выброс :wink:

У мну руки уже давно чешутся наваять на Qt хотя-бы виджет для векторных карт. А роутинг, да чтобы со сбором и учетом статистики скорости - вообще мечта)
В общем, в проекте на Qt я готов участвовать )

А почему нельзя роутинговый граф тоже разбить на куски и хранить/загружать их по-отдельности? И для построения маршрута из точки А в точку Б загружать нужные области, которые лежат между этими точками + ближайшие соседние.

Со мной та же фигня :slight_smile:

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

Но ведь строиться этот граф всё-равно будет по данным OSM и там то эти данные есть. Моя идея такая (это я вообще для себя придумал для генерации 3D тайлов, но по идее и для графов технология должна подойти )

  1. Пользователь указывает точку А и Б
  2. Определяем, какие области нам нужны для построения пути.
  3. Запрашиваем все области
    а) Смотрим, не лежит ли данная область в КЭШе программы, если не лежит то б) иначе пп.4
    б) Проверяем не лежит ли данная область на НАШЕМ сервере, если не лежит, то в) иначе пп.4
    в) Раз мы тут, значит граф для данной области ещё не построен. У нас есть ограничивающий область прямоугольник. Сделаем запрос данных по области (через xapi или ещё как. Можно даже из нескольких источников) и получим векторные данные области. По этим данным сформируем роутинговый граф для нашей области и сохраним его на НАШЕМ сервере, чтобы в дальнейшем другие пользователи могли его оттуда скачать, не затрачивая время на генерацию и сохраняем в КЭШ программы, чтобы повторно не закачивать с сервера.
  4. Берем все графы загруженных областей и строим по ним маршрут.

Вот так я это себе представляю. Само собой я не учитываю сложность при объединении областей графов + возможно другие трудности, которые я пока не вижу.

Кстати, в Qt довольна неплохая поддержка SVG. Если данные OSM конвертить в SVG, а его уже отрисовывать штатными средствами, никакого виджета ваять не потребуется

Спасибо, но С++ я забыл как страшный сон. :slight_smile:

asaw, x10kHz давайте объединимся и С++ вариант стартуем :slight_smile:

PyQt, RubyQt не удовлетворит?

Ну SVG, возможно, подошел бы как способ реализации отображения карты. Однако, ИМХО сабж весьма сложный и со сложностью нужно бороться. То есть, как минимум, разделять интерфейсы и реализацию. В качестве “виджета” я вижу связку типа Model – View – Controller, в которой главное - модель данных. И тут уже, по-моему, SVG совсем не подходит в качестве модели данных. Да и как способ отображения, по-моему, SVG - слишком уж медленно и не слишком элегантно (дополнительное преобразование данных из модели в XML, затем парсинг XML внутри QSvgWidget - получается ещё один лишний “тяжелый” интерфейс).

Давайте. Для начала хорошо бы более-менее окончательно определиться с целями и функциональными/нефункциональными требованиями.

В качестве стартовой точки liosh’ино предложение выглядит весьма разумным.

реализацию рендерера в merkaartor не смотрели?
довольно шустрый. кастомайзится стилями

А смысл? :slight_smile:
Я немного (мне хватает) знаю шарп. Шарп меня всем устраивает. Для моей текущей цели он подходит.

Но вам желаю удачи - она вам очень сильно понадобится - за последнее время тут много проектов старотовало, но я ни одного не видел, который продвинулся дальше этого форумал. :slight_smile:

Кроссплатформенность. Завязываясь на технологии Microsoft, получим 9001-ю софтину Windows-only.

Это меня сейчас меньше всего беспокоит. :slight_smile: