какой gtk, андроид же %)
вот если б виртуальную клавиатуру можно было вызвать…
на компьютере же стоит как раз gtk-гуй, но навит какой-то древней версии, падучий и тормозной, ибо тут без особой надобности.
Давайте формировать список требований к программе.
I этап.
- Программа должна уметь отображать узлы, полилинии и полигоны. В соответствии с набором тегов.
- Должны отображатся подписи объектов, но не как в Navit по контуру объекта.
- Должен работать скроллинг, поворот и масштабирование. Соответственно должен отображаться
компас и масштабная линейка. - Программа должна показывать значком текущее положение.
II этап. - Программа должна уметь записывать трек. Запись должна быть отключаемой.
- В программе должен быть предусмотрено измерение расстояний.
- В программе должна быть предусмотрена возможность прокладки маршрута, используя дороги.
- В программе должно быть предусмотрено проигрывание маршрута.
- В программе должно быть предусмотрена прокладка маршрута по треку.
…
Сначала стоило бы вообще определиться: а чего в результате-то получить хочется? 
Слова “навигационная программа” ещё ни о чём не говорят.
Надо нацелиться на конкретную нишу, должна быть какая-то идея у программы, тогда можно будет оформлять какие-то требования. Просто “Yet another navigation program” делать бессмысленно.
Мне хочется хороший (красивый, читаемый, гибкий и быстрый) рендеринг и прокладку маршрутов (автомобиль, пешком + общ. траспорт). Запись треков (желательно в nmea), вставку меток (в т.ч. голосовых). Отдельный проект - получение высокоточных треков - комплексирование с инерциалкой, одометром и DGPS.
Это необходимо коммерческому проекту. Ибо сразу-же его и убьет. 
Некоммерческий проект этим вопросом заморачиваться не должен. Ибо это смерть до рождения.
Если разработчик сразу нацелится на “хочу супер-пупер того и этого”, то при первых-же
трудностях, которые возникнут уже на первом этапе, он забьет на продолжение.
(Ибо есть бетка очень хорошей программы, которая делается уж три года. Переплюнуть которую надо постараться.
Но возможно, ибо у нее есть минус - она не под все платформы.)
Это какая я же?
Если Вы о программе, то известная в узких кругах во всем мире - Руса. (Не Русса.)
Не вдохновился. Интерфейс такой же кривой, как и GisRX.
Это надо ЛЮБОМУ проекту: понять, кто, зачем и почему будет им пользоваться.
Иначе будет потраченное время и набранный опыт, но достойной программы не получится.
У аффторов этой “очень хорошей программы” как раз этого понимания и не было, ну и результат закономерный.
Давайте подумаем, на каких устройствах будет работать программа. Предлагаю классифицировать по размеру экрана - от 2" до 20", другая классификация становится всё более надуманной.
Черт, у меня монитор 22 дюйма… Это уже попахивает дискриминацией по размеру экрана!
Нужны отдельные экраны с цифрами, например как тут:
http://mapnav.spb.ru/site/
или тут:
http://www.trackmyjourney.co.uk/mobileguide.php? (пролистать немного). (прочитать, ЧТО умеет программа. Как по мне – я не видел ШИРЕ функционала (и я его использую!))
Нужен отдельный список расставляемых заранее или по дороге путевых точек – уметь брать на них направление (показывать) стрелкой (расстояние, курс, етц), уметь список редактировать, уметь редактировать названия путевых точек, позволять вводить/редактировать название ПОЗДНЕЕ. Сохранять их в приличные форматы. (например gpx, kml). И наоборот втягивать в программу из файла-сохранения. Импорт-экспорт, в общем.
Треки. Уметь лить сквозняком на карту nmea, в программу одновременно писать трек с УДОБНЫМИ параметрами – типа Мин.время записи точки (пример: не чаще раза 5 сек) – отключаемое, Мин.расстояние записи точки (пример: не чаще чем через 200 м), уметь при изменении курса ставить дополнительную точку на треке (если расстояние не достигло минимально указанного), уметь симплифицировать трек (например для последующей выработки из такого трека – маршрута), уметь делать из трека маршрут. Маршрут уметь переворачивать в обратную сторону.
И вообще заложить гибкую систему обращения с треками, маршрутами, путевыми точками – конвертить их одно в другое (очень полезно) – как на урове внутри-программых форматов, так и достаточно пространное обилие форматов для импорта-экспорта. Незаменимо в поле/походе – скинул тебе человек по блютусю в поле трек – и тебя не заботит, в каком он формате, сделал из него маршрут, симплифицировал, и поехал.
Конечно, это не первостепенные вещи.
по хорошему, надо точить шаблоны расположения элементов на экране, в зависимости от размера. И шаблонить группы.
Интерфейс - дело второе. И в Русе он вполне юзабельный. Практически ничего лишнего.
Как-то ради интереса померялись c товарищем Русой и Sity Guide.
Я в Русе до центра проложил маршрут за несколько секунд, а товарищ
лазил по менюшкам, коих там мульен, минут 10, да так и плюнул.
Некоммерческий проект делается, как правило, в первую очередь для себя любимого.
Ну и во вторую очередь для комьюнити, “погнуть пальцы”, доставить удовольствие и получить
от этого удовольствие. Это уже достойный повод. А если программа найдет какое-то кол-во
благодарных пользователей, то до ума в процессе доведется.
У “хорошей программы” распался коллектив, так-же как и с весьма успешной в свое время Руссой.
И какждый сам по себе оказался менее успешным, чем коллектив.
Размер экрана? Хе-хе. Это должен взять на себя оконный менеджер. IMHO.
А программа должна работать на максимально возможном кол-ве платформ.
Т.е. основные функции(подпрограммы) должны быть переносимыми.
Можно и вероятно весьма полезно использовать кроссплатформенные библиотеки.
Такие как SDL, wxWidgets. IMHO, Qt не лушее решение, но возможное, на усмотрение разработчика.
Ну, началось. Второй круг go! :3
С этими (и любыми другими) графическими библиотеками закончим за упокой.
В этом случае целевая аудитория вопросов бы не вызывала: “я любимый”. И ниша тоже была бы понятна.
Только вот топик при этом начинался бы не с “давайте придумаем требования”, а с “гляньте, что я для себя любимого наваял”.
Только вот если не ориентироваться на тупых пользователей, то получится очередной проект для гиков (фанатиков).
Чем большее количество пользователей охватит программа - тем лучше для разработчиков.
В программе, например, в настройках, устанавливаем “домашние” города. Если программа видит, что мы выезжаем за пределы города (области), то она сигнализирует нам об этом. После чего пользователь либо игнорирует уведомление, либо отключает GPRS, либо меняет симку.
Автоматизировать можно очень многое - почти всё. 
Не надо сразу собирать кучу требований.
Во-первых потому, что сразу их все всё равно не сделать (если, конечно, разработчик не хочет взять все требования и уйти в подполье писать программу ).
Во-вторых, конкуренты могут их просто утянуть (это у меня небольшая параноя ).
Например, какое-то время назад, CitiGuide проводил конкурс - придумать функцию для их навигационной программы. Я решил поучаствовать. Посидел вечерок - придумал, кажется, идей 10. И хотя, часть из них уже была реализована в платной версии (я пользовался бесплатной, поэтому не знал), тем не менее, другие идеи тоже были довольно интересны (обсуждал их потом с коллегами) и развивали программу в связанных с навигационной областью направлениях. (Например, одна из идей - отслеживание парковочных мест.)
Так вот, если мы сейчас тут напишем интересные идеи, то пока мы только приблизимся к их реализации, конкуренты уже сейчас готовы их писать.
Так что предлагаю пока писать костяк программы:
- Программа должна просто запускаться.
- Программа должна отображать минимум картографических данных (например, только дороги).
- Програмаа должна отображать текущее местоположение от GPS.
Всё.
Так она же какое-то время назад стала платной. Разве нет?
Да и OSM не поддерживает(ла).