mapsoft -- набор библиотек и программ для работы с картами и gps-данными. Довольно сложный и запутанный. Пишется совместно с М.Ушаковым и Т.Алексеевским
ph_scripts -- набор скриптов для работы с фотографиями. В частности, программа, с помощью которой я делаю отчеты и фотоальбомы для slazav.mccme.ru.
imgdiff -- простая показывалка двух картинок рядом. Была написана для использования в git-diff при хранении фотографий в git, может быть использована для просмотра стереопар. Программа (зачем-то) лежит в репозиториях AltLinux. Для сборки требуется gtkmm-2.4
akk -- простая подсказывалка аппликатуры аккордов для 6-струнной гитары. Показываются все положения входящих в аккорд нот, раскрашенные по-разному в зависимости от функции в аккорде. Для сборки требуется gtkmm-2.4.
word2pnm -- "генератор юзерпиков", читает данные с stdin
(лучше в небольшом количестве, несколько байт) и, вдохновленная ими,
рисует картинки. Возникла как ответ на всякие идеи про представление
отпечатков ssh-ключей в виде запоминающихся картинок.
Изначальная идея была вполне физическая, про шарик, летающий в ящике,
отталкивающийся от стенок и управляемый входными данными. Для того что
получилось, никакой разумной физической интерпретации уже, видимо,
нет. Все сделано в целых числах, с помощью издевательств над
алгоритмом Брезенхема.
Преобразование разных форматов GPS-данных, в том числе в графический формат fig для просмотра/редактирования. (PERL, 2002 год)
Программа старая и не очень аккуратная, но я до сих пор работаю именно с ней.
Программа работает как фильтр, понимаются файлы в форматах:
Вызывать программу надо так:
./gps_conv <ifmt> <ofmt> < <ifile> > <ofile>
ifmt -- формат входного файла (oe, gu, gt, fig)
ofmt -- формат выходного файла (oe, gu, gt, fig[:<parfile>])
parfile -- файл параметров для вывлда в fig-файл
Для записи в формат fig можно написать файл параметров, но можно и не писать, установки по умолчанию достаточно разумны (масштаб 1:100000, сетка 2х2 см, размер сетки определяется автоматически, чтобы влезли все точки). Пример файла параметров (с установленными значениями по умолчанию) -- в файле ./param
При записи fig-файла координаты строятся в проекции Гаусса-Крюгера для эллипсоида WGS84. Для этого используется программа ./pj, которая в свою очередь требует библиотеки libproj Это немного неудобно, так как сетка не совпадает с сеткой советских карт. Нужно совмещать схему с картой не по сетке, а по точкам и треку. (А сделать по-нормальному - лень :))
В fig-файл рисуется прямоугольная сетка, подписи к ней, реперные точки в углах, и собственно трек и точки.
По реперным точкам производится обратное преобразование. Вы можете перемещать, масштабировать, поворачивать сетку с точками, после этого файл будет правильно читаться программой gps_conv. Нужно только проследить, чтобы реперные точки не пропали.
Дополнительная информация в fig-файле сохраняется в комментариях. Комментарий к реперной точке выглядит следующим образом:
# CRD XXXXX YYYYY
где XXXXX и YYYYY -- координаты Гаусса-Крюгера (в метрах)
Вы можете сами создать реперные точки и тем самым привязать карту. Надо только помнить, что координаты Гаусса-Крюгера надо давать для системы координат WGS84 :( Комментарий можно вводить из команды edit xfig'а.
Комментарий к точке:
# WPT NAME # COMMENT # YYYY-mm-dd HH:MM:SS # ALT
Где NAME - имя точки (используются первые 6 символов [A-Z_0-9] после пробела), COMMENT -- комментарий (используются первые 16 символов [A-Z_\-0-9: ] после пробела) YYYY-mm-dd HH:MM:SS -- дата и время (всегда GMT) ALT -- высота в метрах. Имена точек могут совпадать, это никак не проверяется
Если вы вводите точку сами, обязательной является только первая строчка. При наличии 2-й, 3-й, 4-й строчек, информация читается и из них.
Комментарий к треку:
# TRK ID # start: DATE1 # stop: DATE2 # N points
ID -- имя кусочка трека. По нему будут рассортированы кусочки при преобразовании в другой формат. Могут совпадать, тогда результат сортировки будет произвольным. DATE1 и DATE2 -- даты и времена начала и конца трека N -- число точек в треке. При чтении трека из fig-файла учитывается только первая строчка комментария. Таким образом, при преобразовании, *->fig->* теряется информация о датах и высотах в треке и сохраняется вся информация о waypoint'ах.
Поля, используемые для разных форматов в скобках -- значение по умолчанию при записи:
gt gu oe fig
-----------------------------------------
wpt: NAME +("") +("") +("") +("")
LAT +(0) +(0) +(0) +(0)
LON +(0) +(0) +(0) +(0)
ALT - - +(-777) +(0)
COMM +("") +("") +("") +("")
DATE +(0) - +(0) +(0)
SYM - +(0) - -
DYSP - +(0) - -
-----------------------------------------
trk: SF +(1) +(1) +(1) +(1)
LAT +(0) +(0) +(0) +(0)
LON +(0) +(0) +(0) +(0)
ALT - - +(-777) -
DATE +(0) +(0) +(0) -*
-----------------------------------------
* - при записи треков в формате fig даты
начала и конца трека пишутся в комментарий.
Попытка написать более продвинутую версию конвертера gps-данных (PERL, декабрь 2004).
Здесь сделан гораздо более аккуратный разбор файлов Ozi-Explorer'a, поддершивается также формат garmin-utils.
Самая новая, совместная с М.Ушаковым попытка написать конвертер gps-данных "и все остальное" (C++, boost/spirit, осень 2005). Проект пока жив, некоторые кусочки обсуждения (довольно непоследовательные и отрывочные) есть на http://wackowiki.com/MaxUshakov/GPSSoft
На данный момент готов ввод/вывод данных в "xml-подобный" формат и кусочек разбора формата garmin-utils. Короче, смотреть здесь пока не на что, но если кто-то хочет помочь (например, советом) - будет хорошо!
Библиотека для склейки сканированных карт из кусочков (C, ноябрь 2004).
Есть матрица NxM мест для кусочков. Мы последовательно кладем кусочки в матрицу, задавая для каждого по четыре контрольные точки (примерно по углам).
Первый кусочек ляжет без изменений, второй кусочек подклеится к первому, повернувшись/растянувшись нужным образом, и т.д.
Если кусочек достаточно свободный (имеет не более одного соседа), его можно выровнять (задав пару точек, которые должны лежать на вертикали или горизонтали).
В качестве примера приведено склеивание карты из 2х2 кусков с выравниванием.
Первая более-менее успешная попытка трассировать речки (C++, весна-лето 2005). Работает с отдельным srtm-файлом (что неудобно).
Трассировка речек сделана следующим образом: Сначала вся поверхность "затапливается", то есть строятся области одинаковой высоты ("лужи") и, если такая лужа получается бессточной, ее уровень повышается, пока рядом не окажется более низкая точка. (Здесь надо иметь в виду одну хитрость, "обратное затопление", когда лужа затапливает лужи, которые уже слились в нее) После этой процедуры гарантируется, что из каждой лужи можно легко найти путь вниз. После этого можно построить дерево луж, считать площадь водосбора и уклон речек...
В качестве примеров:
Cледующий подход к srtm'у (C++, осень 2005)
Есть библиотека доступа к SRTM-данным (объект типа srtm). Она знает про
директорию с файлами (имена файлов должны иметь вид N29E101.hgt) и
загружает их по мере необходимости. При инициализации можно указать
директорию, размер кэша и указать, надо ли интерполировать дырки.
Таким образом, можно получить высоту точки с любыми координатами, лишь
бы был файл соответствующий файл данных.
Примеры:
Проект пока жив! В перспективе: попробовать сделать локальный поиск
речек (без построения дерева на всей поверхности), посчитать площадь
водосбора Енисея и т.д...
srtm02