Так давай перейдём. Этот текст тут закрывается, текст там вот: 
http://npj.ru/gpssoft/gps_soft
Для трёх, более или менее, целей.
Или, что то же самое,
Вообще, существующая система с xfig'ом более-менее все это позволяет. Но имеет ли смысл развивать именно ее – непонятно.
Может быть, годится такая Схема Утилит?
Обсуждаются в разделе Архитектура Программ.
Попробую здесь описать архитектуру того, что уже есть, по директориям.
jeeps
Очень приятная библиотека для связи с gps-приемниками. К сожалению, в чистом виде мне не удалось ее найти. Так что взял из gpsbabel и подправил немного. (Сам gpsbabel, мне, кстати, не особенно понравился). jeeps работает, кажется, со всеми новыми garmin-приемниками, через serial port и libusb, кажется, ее можно скомпилировать и под windows — очень интересно, если кто-то это попробует сделать!
Также в jeeps есть и различные процедуры для преобразования систем координат – все, что нам когда-либо может понадобиться!
В директории jeeptest есть несколько глупых примеров использования, вероятно, их когда-нибудь надо удалить...
io
Библиотека для чтения/записи геоданных.
Все данные представлены в виде системы вложенных объектов (см. data.h):
Имеются процедуры для чтения/записи таких объектов в файлы разного формата. Для разбора файлов используется boost/spirit и boost/lexical_cast. (Вероятно, в основном из-за лени и любопытства :))
* xml — такой «xml-подобный» формат, замечательный тем, что отображает без измненений все данные из внутреннего представления на диск (и обратно). При этом каждый объект представляется в виде тэга с соответствующим названием, атрибутами и вложеными тэгами. (В xml-файле может находиться несколько объектов). В хml формат записываются/читаются объекты любого типа. Для всех остальных форматов пока поддерживаются только объекты типа “waypoints” и “track”, причем в каждом из них должны содержаться объекты типа “pt”.
Подробнее про map-файлы: http://www.rus-roads.ru/gps/help_ozi/map_file_format.html
* gu — старый формат программы garmin-utils (кажется, это формат примерно версии 1.4, сейчас он, вероятно, уже изменился). Важен мне из исторических соображений: до недавнего времени я пользовался именно этой программой и большинство моих gps-данных хранится в таком формате. Может быть, этот формат подойдет и для записи файлов вручную или простыми скриптами. Других причин пользоваться им я уже не вижу.
* oe — формат OziExplorer. Пока поддерживается чтение и запись wpt- и plt- файлов и не вполне полноценное чтение map-файлов. При чтении распознаются системы координат wgs84 и pulkovo42, проекции карт "Latitude / Longitude?" и Transverce Mercator".
todo – доделать запись map-файлов (границы изображения и размеры файла — Кстати, чем бы правильнее узнавать размеры граф.файла?).
* gps — это интерфейс к библиотеке jeeps — запись и чтение данных с gps-приемника.
Таблица совместимости тэгов и параметров:
| gps | gu | oe | комментарии | |
| track | ||||
width | rw | |||
displ | rw | |||
color | rw | rw | ||
comm | rw | rw | ||
skip | rw | |||
type | rw | |||
fill | rw | |||
cfill | rw | |||
| track/pt | ||||
lat | rw | rw | rw | |
lon | rw | rw | rw | |
time | rw | rw | rw | |
alt | rw | rw | ||
depth | rw | |||
start | rw | rw | rw | |
| waypoints | ||||
symbset | rw | |||
| waypoints/pt | ||||
lat | rw | rw | rw | |
lon | rw | rw | rw | |
name | rw | rw | rw | |
comm | rw | rw | rw | |
alt | rw | rw | ||
symb | rw | rw | rw | |
displ | rw | rw | rw | |
color | rw | rw | ||
bgcolor | rw | |||
time | rw | rw | ||
map_displ | rw | |||
ptdir | rw | |||
prox_dist | rw | |||
font_size | rw | |||
font_style | rw | |||
size | rw | |||
| map | ||||
proj | rw | “tmerc” или “latlon” | ||
file | rw | Название файла с картой | ||
comm | rw | Название карты. Надо ли его преобразовывать в win1251->koi8? | ||
border | r | Граница изображения в координатах карты | ||
| map/pt | ||||
x | rw | |||
y | rw | |||
lat | rw | |||
lon | rw | |||
converter
Программа, конвертирующая перечисленные выше форматы данных.
./convert <in1> ... <inN> -o <out>
Формат входных файлов определяется автоматически. Поддерживаются «xml-подобный» формат, garmin-utils, Ozi Explorer?.
Формат выходного файла определяется по его расширению:
.xml — xml
.gu — garmin-utils
.wpt, .plt, .map, .oe, .zip — Ozi Explorer?
В формате Ozi Explorer'a? может записываться много разных файлов за один раз, например: a.wpt, a1.plt, a2.plt, a3.plt, при этом их расширения зависят только от того, что в них находится, а не от указанного изначально расширения... Если было указано расширение .zip, то все эти файлы потом зазиповываются.
Чтение zip-файлов пока не сделано, хотя это было бы очень полезно...
Если среди имен входного или выходного файлов попадется имя символьного устройства или слово “usb:», то произойдет связь с gps-приемником (через последовательный порт или libusb).
Примеры
Скачать данные с gps через usb, записать их в zip-архив:
./convert usb: -o aaa.zip
Закачать в gps все треки:
./convert *.plt -o /dev/ttyS0
Почти вся работа converter'a сейчас перенесена в io/io_file.cpp
map
Построение различных преобразований для файла привязки. Замечательная штука получилась!
Примеры использования см. в директориях sdl/ и mergemap/
От класса RPoint я решил здесь отказаться.
todo — быстрая проверка, лежит ли координатное окно целиком вне карты или целиком в карте.
sdl
Ленивые попытки разобраться с libsdl, чтобы рисовать что-нибудь на экране :)
./test2 <геоданные> — Рисует треки и точке на привязанной карте (которая должна быть среди входных файлов).
mergemap
./mergemap <геоданные> — склеивает все карты в проекции Гаусса-Крюгера, накладывает на них треки и точки.
Результат записывает в Jpeg-файл.
В качестве примера даны 4 карты, xml-файл привязки для них и какой-то трек.
Ценное в программе — правильное чтение/запись цвета с поверхности SDL.
todo
При скачивании из GPS60 активный трек называется “ACTIVE LOG”. При записи в GPS трека с таким названием получается ошибка. При записи трека с названием, которое начинается на “ACTIVE LOG” (например “ACTIVE LOG1”) трек добавляется к активному. При записи трека с любым другим названием – он записывается в сохраненные треки. Надо ли как-то обходить такую ситуацию – не очень понятно.
gps после включения всегда распознается только со второго раза...
Чем отличается Ozi Track Point File Version 2.0 от 2.1? Никаких отличий я не обнаружил, читаю одинаково.
Так же, одинаково читаю и Map 2.0, 2.1, 2.2 (замеченные различия несущественны)
Все координаты хранятся в градусах WGS84.
Высота не преобразуется.
Про привязанную карту мы хотим хранить следующую информацию:
* название карты
* название файла с картой
* проекция карты (для начала — “latlon” или “tmerc”)
* граница карты (многоугольник в координатах граф.файла)
* точки привязки (x, y — координаты в граф.файле, lat, lon — координаты wgs84)
Мы не будем хранить СК и параметры поперечно-цилиндрической проекции карты, считая, что изменения этих параметров ведет лишь к линейному ее преобразованию. Таким образом, все преобразования карты сведуться к преобразованию latlon <-> tmerc (в зависимости от того, в какой проекции нарисована исходная карта и в какой мы хотим ее нарисовать) для wgs84 (а то и для сферической Земли :)) и разумного осевого меридиана, и, после этого, к линейному преобразованию, которое мы будем находить по точкам привязки (минимизацией среднеквадратичного отклонения – если точек больше трех).
При рисовании карт и gps-данных мы можем работать в одном из трех миров:
* latlon. Прямоугольные координаты – широта и долгота.
* tmerc с переключением — обычные координаты Гаусса-Крюгера, координаты – x,y и номер зоны. При рисовании зоны можно делать перекрывающимися, а переключения между ними – вручную.
* tmerc с поворотом — координаты Гаусса-Крюгера, повернутые так, чтобы карта была ориентирована на север. Тогда соседние зоны будут более-менее правильно склеиваться (особенно на крупных масштабах) и пользователю не надо будет заботиться об их переключении. Но кажется, с построеием такого мира возникнет куча проблем, а полезность и аккуратность его будет сомнительной.
При этом нам не нужны построения преобразований между двумя произвольными привязками, а нужно для каждой привязанной карты найти лишь преобразования в каждый из миров и обратно.
Что и сделано в map/mymap.h
