Карты ресурса “Поехали” канули в лету, хоть они и не блистали своим качеством. Теперь их можно найти на различных торрентах в сбониках и т.д. Данная заметка, что бы после было можно оперативно найти себе карту (привязать, кропнуть, склеить, сделать jnx :simple_smile:) для похода.
UPD 2019-11-14:
Старые генштабовки
Карты Госгисцентра
Которые утекли на просторы интернета, скачиваются на торрентах с
http://rutracker.org, поиск по слову “ggc”. Отдельно стоит отметить то, что к ним есть привязки (там же на торрентах) в трёх форматах:
- OZI Explorer
- Global Mapper
- World
Последние представляют из себя пару файлов с расширениями .prj (описание проекции в тестовом формате Well-known_text|WKT (Well-Known Text)
) и .pgw (файл с 6 строчками с цифрами - сам Wold файл) и могут быть использованы gdal_translate
для получения привязанного GeoTIFF (об этом я вскользь уже упоминал:
Проблема с gdal: система координат LOCAL_CS вместо PROJCS [SOLVED] )
Полный набор можно скачать с раздачи на nnm-club:
http://nnm-club.ru/forum/viewtopic.php?t=403156 только раздача очень жирная, на моём нетбуке открыть её не получилось :)
Наличие самих карт можно смотреть на неофициальном сайте:
http://loadmap.net (старый генштаб тут же).
DEM рельеф
Особенно полезен в различных картографических программах, вроде QLandkarteGT, для планирования маршрута, дневных переходов, т.к. предоставляет карту высот и мы может увидеть график высоты, оценить, стоит ли подниматься на перевал с этой стороны или выбрать другой вариант.
SRTM данные, в формате, поддерживаемом gdal можно скачать тут (официальный сайт):
http://dds.cr.usgs.gov/srtm/version2_1/SRTM3
Файлы там имеют структуру: NddEddd.hgt.zip, где N - северная широта (S - для южной), dd - градусы широты, E - восточная долгота (W - для западной), ddd - градусы долготы. Сайм файл рельефа покрывает площать 1x1 градус. Датум у этих файлов WGS84, для использования с генштабовскими картами, нужно будет преобразовать систему координат с помощью gdalwarp
(на выхода правда получится уже не hgt, а GeoTIFF - но почти все программы такой вариант представления высоты тоже понимают)
Этими же файлами можно разжиться в двух раздачать на торрентах:
Для широт севернее 60 градусов северной широты можно данные можно взять тут:
http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm
Векторные карты
Для начала, для навигаторов Garmin, а вообще не раздел, а один сплошной TODO, т.е. все рекомендации приветствуются.
- Приморский край, “Приморский край ТОПО”:
http://dvmaps.narod.ru/pkmap.htm
- Камчатка, домашние вулканы (сам был в том походе, для которого она делалась и по результатам которого обновлялась):
http://dvmaps.narod.ru/HomeVulc-map.htm
- И вообще карты:
http://dvmaps.narod.ru/download.htm, кроме вышеперечисленных, качество которых я лично могу подтвердить, на момент написания данного поста имеется:
- Алтай, Катнуский хребет, г.Белуха 1:50000, карта для GPS Garmin
- Карта Северного прибайкалья (г.Черского, оз.Фролиха) масштаб 1:50000 для GPS Garmin.
- L-54-11 Южно-Сахалинск, подробная карта СТК “Горный Воздух”, 1:100000, для GPS Garmin
- Баджал, улунский цирк, M-53-053, 1:100000, карта для GPS Garmin
- O-56-014 Магадан, 1:100000, карта для GPS Garmin
- Заилийский Алатай, сырая незаконченная карта для GPS Garmin
- хребет Баджал, 1:100000, незаконченная карта для GPS Garmin
- Ергаки, 1:30000, карта для GPS Garmin
- Мунку-Сардык, 1:30000, карта для GPS Garmin
- Борус, 1:50000, карта для GPS Garmin
- Мана, 1:50000, карта для GPS Garmin
- Тункинские гольцы, 1:50000, карта для GPS Garmin
-
Туристические карты для GPS-навигаторов, не густо, но вроде как принимают заявки на изготовление.
-
Самодельные векторные карты для GPS-навигаторов - очень неплохая коллекция
-
http://karty-garmin.ru/ - пока ничего сказать не могу. Взял карты Абхазии.
Бывает необходимость в вашем приложении отобразить ту или иную стандартную системную иконку, типа значка диска CD-ROM. Можно, конечно, создавать свой ресурсный файл и ложить иконки туда, но это будет выглядеть несуразно, особенно при смене различных тем оформления. Задаёмся резонным вопросом: а как бы использовать то, что уже есть в Qt и/или системе?
Вариант 1: стандартные ресурсы Qt4
Про это написано тут:
http://www.qtcentre.org/wiki/index.php?title=Embedded_resources
Помимо списка, приведён и код, которым можно получить список самостоятельно. Так же показан пример, как создавать изображение из ресурса:
QPixmap pixmap(":/trolltech/styles/commonstyle/images/up-128.png");
QIcon icon(":/trolltech/styles/commonstyle/images/up-128.png");
Вариант 2: стандартные иконки при помощи QStyle
Сылки по теме:
-
http://doc.trolltech.com/latest/qstyle.html#standardIcon
-
http://doc.trolltech.com/latest/qstyle.html#StandardPixmap-enum
Собственно что нам нужно, это метод класса QStyle:
QIcon QStyle::standardIcon ( StandardPixmap standardIcon, const QStyleOption * option = 0, const QWidget * widget = 0 ) const
Иконки опеределяются перечислением
StandardPixmap
Вариант 3: использование иконок темы оформления
Тут, скорее всего, всё будет очень сильно зависеть от платформы. Но в общем случае, нам нужен такой вызов:
QIcon icon(QIcon::fromTheme(QString::fromUtf8("icon-name")));
icon-name
имя иконки, возможные значения, стандартные, для Linux можно узнать тут:
http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
На выходных готовил растровую карту для похода на Кодар, с последующей конвертацией оной в JNX.
Самые неинтересные и скучные моменты в этом деле была обрезка рамки. А кроме того, печаль, по причине того, что есть карты с привязками OZI, но нет нормального конвертера для них.
В результате, подумал и написал за выходные две программы: ozi2map и geocrop
ozi2map
Данная утилита более не актуальна. Версия GDAL (>=1.10), входящая во все популярные дистрибутивы, уже умеет сама обрабатывать такие MAP файлы.
Первая, как можно понять из названия, предназначена для конвертации карты с привязкой OZI (сама карта в JPEG или GIF или другом распространённом растровом формате, который поддерживает OZI, но не OZFX/OZFX2/OZFX3, для них преобразования можно сделать средствами самого gdal (в прошлых статьях писал про это)).
Для чтения точек привязки и параметров проекции используется функция из недр GDAL: GDALReadOziMapFile(...)
, что, в отличии от питоновского ozi2geotiff.py, даёт корректные параметры проекции. Далее, не стал особо заморачиваться и подсовывая нужные параметры gdal_translate/gdalwarp вызываю их через system()
.
Я вообще не стал лезть в разбор map файла, поэтому файла растра автоматически не определяется и его нужно указывать самому:
./ozi2map O-50-103.map O-50-103.jpg
./ozi2map O-50-103.map O-50-103.jpg O-50-103.tif
Если имя выходного файла не задано, имя будет сформировано из имени растра с заменой расширения на .tif.
Всё, пользоваться программой должно быть проще простого. Найти исходники (GPLv2) можно тут:
https://git.gitorious.org/h4tr3d-utils/ozi2map.git
Собирать просто:
make
Полученный бинарник можно запускать от куда угодно.
geocrop
Вторая программа предназначена для автоматической (хотя лукавлю: полуавтоматической) обрезки рамки на номенклатурном листе. Принцип действия прост: определённому набору координат соответствует какой-то стандартный лист заданного масштаба (его как раз и нужно указывать). Стандартный лист обрамлён вполне конкретными координатами, по которым вполне можно осуществить обрезку без вмешательства человека.
Т.е. по сути, программе на вход нужен только масштаб листа (в виде 1M, 500k, 200k, 100k, 50k, 25k, 10k, 5k, 2k) и сам лист карты в формате, поддерживаемом GDAL с корректной привязкой.
Когда расчёты по привязке будут выполнены, вызывается gdalwarp через system()
. Полигон для обрезки формируется в координатах листа (не в точках растра), для всех листов, кроме 1M, это 4х угольник (на будущее будет более качественно сделано, но и текущего результата хватит в 99.99% случаев).
Пользоваться программой не сложнее чем ozi2map:
./geocrop -s 100k O-50-103.tif O-50-103-crop.tif
Первым аргументом - стилизованное обозначение масштаба:
- 1M - 1:1 000 000 (это масштаб используется, если мнемоника не распознана)
- 500k - 1:500 000 (“пятикилометровка”)
- 200k - 1:200 000 (“двухкилометровка”)
- 100k - 1:100 000 (“километровка”)
- 50k - 1:50 000 (“полукилометровка” или “пятисотметровка”)
- 25k - 1:25 000 (“двухсотпятидесятиметровка”)
- 10k - 1:10 000 (“стометровка”, пока не реализовано)
- 5k - 1:5000 (“пятидесятиметровка”, пока не реализовано)
- 2k - 2:2000 (“двадцатиметровка”, пока не реализовано)
Если этот параметр пропущен, используется масштаб 100k.
Вторым аргрументом - входной файл, поддерживаемый GDAL.
Третий аргумент - выходной, кропнутый файл. По умолчанию - GeoTiff, но можно переопределить опцией “-f FORMAT”, где FORMAT - любой поддерживаемый GDAL.
Если хотите обрезанные карты потом склеивать при помощи gdal_merge.py
, и получить вразумительные результат, входной файл должен быть в цветовой палитре RGB, узнать это можно при помощи утилиты gdalinfo
, если в выводе есть такое:
Band 1 Block=4096x1 Type=Byte, ColorInterp=Red
Band 2 Block=4096x1 Type=Byte, ColorInterp=Green
Band 3 Block=4096x1 Type=Byte, ColorInterp=Blue
значит всё хорошо, если нет (выводится палитра из 255 цветов), то палитра индексированная, нужно преобразовать в RGB при помощи утилиты pct2rgb.py
из комплекта GDAL.
Собирать просто:
mkdir build
cd build
cmake ..
make
Если на стадии cmake будут какие-то проблемы, стоит поставить dev-пакеты для GDAL и PROJ.4
Исходники можно взять тут (GPLv2):
https://github.com/h4tr3d/geocrop
Суть проблемы: при отработке утилит вроде
ozi2geotiff получался geotiff который потом не читался в том же QLandkarteGT и утилитами самого gdal (типа того же gdalwarp). Самое печальное, что это коснулось и файлов привязок для карт с росгисцентра (в формате .pgw + .prj (первый - привязка в формате ESRI World file, второй - описание проекции в формате WKT((Well Known Text))), картами и привязками можно разжиться
тут или на
http://rutracker.org поиском по слову ggc).
Печально потому, что если положить рядом файл карты в .png, файл привязки .pgw и описание проекции .prj (имя файла без расширения при этом должно быть одинаковым), то получить geotiff становится проще простого:
gdal_translate -of GTiff -a_srs O-50-103-D.prj O-50-103-D.png O-50-103-D.tiff
Файл .pgw подхватывается автоматически, дополнительно его указывать не нужно (об этом же говорится в официальной документации про поддержку PNG:
http://www.gdal.org/frmt_various.html).
В печали я написал в список рассылки разработчиков gdal, к утру получил ответ от Frank Warmerdam, с уведомлнем, что он попытался на последне версии gdal и проблемы не наблюдает. Попытался собрать и тоже проблема самоустранилась, при этом, gdalinfo выдал корректную информацию для файлов сгенерированных старым gdal_translate, эти же карты после обновления открылись и в QLandkarteGT. Так что, у кого стоит gdal 1.9.0, нужно срочно обновляться (вроде как проблемы нет уже в 1.9.1, но не проверял)
Полезные ссылки:
В интернетах уже есть заметки по этой тематике, например ссылки приводил в
post/2009-03-15_11.42_paru_zametok_o_qlandkartegt, но что бы было под рукой. Опускаться до того, в какой пункт меню заходить не буду, приведу чисто технические моменты.
Исходные данные: лист километровки О-50-103.tiff
На первом шаге нужно указать проекцию карты, для нашего родного генштаба проекция будет примерно такого вида:
+proj=tmerc +lat_0=0 +lon_0=117 +k=1 +x_0=20500000 +y_0=0 +ellps=krass +units=m +no_defs
+proj=tmerc +lat_0=0 +lon_0=117 +k=1 +x_0=20500000 +y_0=0 +ellps=krass +towgs84=23.9,-141.3,-80.9,0,-0.37,-0.85,-0.12 +units=m +no_defs
(параметр towgs84, определяет параметры перехода к датуму wgs84, который используется в том же GPS, этот параметр автоматом добавится, если в мастере настройки проекции выбрать датум Pulkovo 1942)
собственно для каждого листа миллионки она будет своя, жирным выделено то, что будет меняться от листа к листу. Теперь пояснения:
- lon_0 - центральный меридиан
- x_0 - мнимый восток (false easting)
В статье
post/2011-06-26_14.58_gotovim_rastrovuju_kartu_dlja_navigatora_garmin_gpsmap_62s я уже показывал как рассчитывать эти параметры, продублирую и здесь:
lon_0 = Nз * 6 - 3 # центральный меридиан по известной зоне
x_0 = Nз * 1000000 + 500000 # мнимый восток (false easting)
Nз = floor(lon / 6) + 1 # номер зоны по любому значению долготы на листе, floor - взятие целой части от деления
Nз = (lon_0 + 3) / 6 # номер зоны по центральному меридиану (частный случай)
Как видно, оба параметра зависят от номер зоны, что бы не заморачиваться, есть ещё один очень простой способ определения её: по номеру листа, вычитая из него 30. Т.е. лист у нас O-50, значит его номер - 50, тогда:```scilab
Nз = 50 - 30 = 20
Тогда значения центрального меридиана и мнимого востока:```scilab
lon_0 = 20 * 6 - 3 = 117
x_0 = 20 * 1000000 + 500000 = 20500000
Так же, для простоты, можно принять, что мнимый восток это: 500000 перед которым написан номер зоны, как он есть, т.е. как результат объединения двух строк (в программировании):```
“20” + “500000” = “20500000”
Давно пользуюсь услугами cppcheck, но решил поглядеть что есть ещё (как оказалось, лучше, по сути, ничего и нету). Наткнулся на статью по теме на хабре:
http://habrahabr.ru/post/75123
Тезисно:
Далее,
Анализ утилит статического анализа C++ кода, автор рассматривает следующие анализаторы:
- rats (выше писал)
- cppcheck (аналогично)
- Graudit (есть в AUR)
причём рассматривает проблемы, которые они не выявляют.
Список статических анализаторов можно поглядеть на страничке в википедии:
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis, причём не только для C/C++
Для интереса можно почитать перевод статьи Джона Кармака о статическом анализе:
http://habrahabr.ru/post/135234/((Оригинал статьи: altdevblogaday.com/2011/12/24/static-code-analysis/)), где кратко излагается, какими инструментами ему довелось воспользоваться, и какие впечатления остались после них.
И на последок серия из четырёх заметок камрада
Andrey2008((Один из разработчиков PVS-Studio, поэтому малость пропускаем его отсылы к этому продукту)) “Как уменьшить вероятность ошибки на этапе написания кода”:
-
Заметка №1:
- Избегайте функции memset, memcpy, ZeroMemory и им аналогичные
- Внимательно следите, работаете вы со знаковым или беззнаковым типом
- Избегайте большого количества вычислений в одной строке
- Выравнивайте в коде всё, что возможно
- Не размножайте строку более, чем один раз
- Выставляйте высокий уровень предупреждений у компилятора и используйте статические анализаторы
-
Заметка №2
- Не используйте тернарную операцию ‘?:’ в составных выражениях
- Не стесняйтесь использовать скобки
-
Заметка №3 - на примерах ошибок в Qt4
- Обрабатывайте переменные в той же последовательности, как они объявлены
- Табличные методы — это хорошо
- Разное интересное (про разные и интересные ошибки в Qt4)
-
Заметка №4 - на примерах ошибок в Firefox
Проблема странная, проявляется не сразу: вроде при запуске всё отлично работает, потом бац, перестаёт, при этом выводится сообщение слудющего содержания:
Error: in bind call: /home/user/.config/luakit/webview.lua:341: attempt to perform arithmetic on local 'p' (a nil value)
Решение проблемы нашёл тут:
https://github.com/mason-larobina/luakit/issues/68, нормальный рабочий вариант получается этот:
https://github.com/mason-larobina/luakit/issues/68#issuecomment-5528890
На правах заметки: цикл статей о многопоточности в C++.
В цикле рассматриваются создание обёртки над pthreads((ссылки по теме:
- POSIX_Threads
-
POSIX Threads Programming
-
Краткое описание pthread (threads))), использование
boost::thread, а так же использование идиомы RAII|RAII (Захват ресурса есть инициализация)
в контексте потоков.
Вообще, блог
Empty Crate крайне рекомендую к ознакомлению - интересные заметки по программированию на C++.
Так же в тему многопоточности concurency в C++0x (но всё это можно переложить, с небольшими оговорками и на boost::thread) серия статей в блоге Just Software Solution:
Достаточно запустить:
dia –integrated
теперь вполне можно пользоваться.
Ну и чуть ярости: ну какого чёрта не вынести это в настройки!?
Первый тестовый пост после обновления PHP с 5.3.10 на 5.4.3 и отказа BlogTNG.
Причина: BlogTNG использует SQLite2, который выкинули из PHP 5.4.0.
Не всё делается одинаково во всех компиляторах, не на всех платформах, приходится временами городить хитрые конструкции из #if/#elif/#endif. Случайно наткнулся на шпаргалку, в которой описано, какие директивы препроцессора предопределяют конкретные компиляторы:
http://sourceforge.net/p/predef/wiki/Compilers/
С того же ресурса:
А так же определение порядка байтов:
http://sourceforge.net/p/predef/wiki/Endianness/
Другие ссылки на эту тематику:
- C++ Containers Cheat Sheet:
1.
http://homepages.e3.net.nz/~djm/cppcontainers.html
2.
http://habrahabr.ru/company/infopulse/blog/194726/
- C++ Iterators & Algorithms Cheat Sheet:
1.
http://homepages.e3.net.nz/~djm/cppiterators.html
- Shifting from C to C++ strings:
1.
http://homepages.e3.net.nz/~djm/cppstrings.html
- C++03 vs C++11:
1.
http://dl.dropboxusercontent.com/u/13100941/C%2B%2B11.pdf
- C++ Quick Reference:
1.
http://www.dreamincode.net/downloads/ref_sheets/cpp_reference_sheet.pdf
- STL Quick Reference:
1.
http://www.digilife.be/quickreferences/QRC/STL%20Quick%20Reference%201.29.pdf
- C++ Concurency:
1.
http://cpprocks.com/wp-content/uploads/C++-concurrency-cheatsheet.pdf
Отдельно по ANSI C:
http://www.digilife.be/quickreferences/QRC/C%20Reference%20Card%20%28ANSI%29%202.2.pdf
Цикл статей камрада
Игоря Кальницкого для “самых маленький” про плюшки нового стандарта C++:
-
Введение в C++11: auto, decltype, nested templates и range-based-for
-
Введение в C++11: nullptr и нововведения в системе инициализации
-
Введение в C++11: лямбда функции
-
Введение в C++11: умные указатели
-
Введение в C++11: новые спецификаторы
-
Введение в C++11: пользовательские литералы
Так же стоит прочитать статью на Википедии, на удивление информативная: C++11
А как оказалось, на разделе с /tmp кончилось место, сказал об том Midnight Commander при запуске.
Надеюсь, что всё таки выберемся за пределы орбиты Земли..