23 февраля решили отпраздновать очередным снегоступингом.
По предложению Кирилла рассматривали варианты посещения южных отрогов Ливадийского хребта.
Маршрут изначально рассматривался как:
Фокино-г.Халаза-г.Горбуша-г.Лысый дед-Молёный мыс
но в результате был скорректирован до:
Душкино-падь Светланка-г.Круглая-г.Пидан-Лукьяновка.
Собралось три человека: я, Кирилл, Саня. В роли адового тропильщика в этот раз Кирилл.

Я подумал и решил, что функционала и стабильности достаточно для релиза версии 1.0.
Так что да будет так: https://github.com/h4tr3d/geocrop/releases/tag/v1.0
Если у вас на входе привязанный GeoTIFF, то проблем нет никаких, но если у вас просто растр (.png, .jpeg, .gif) и привязка для него, то есть нюансы. Вообще, GeoCrop умеет работать с любыми данными, с которыми умеет общаться GDAL. Но в в некоторых случаях не всё получается гладко, так, например, только сегодня он научился читать файл проекции для world-привязок (пара .prj+.pgw).
На просторах интернета можно встретить различные описания привязок, самые популярные:
Ozi Explorer
GDAL не умеет только шифрованные OZFX, а так привязанная карта представляет собой пару .map+растр, где растр - это, обычно, .gif, .jpg или .png, реже - .bmp. При наличии такой привязки geocrop можно вызвать без дополнительных приготовлений:
geocrop -f VRT -s 50k K-53-026-A.map K-53-026-A.vrt
Обратите внимание, что передаётся map файл, а не растр.
World files
Т.к. сама привязка состоит из двух файлов (.prj+.pgw), то не так просто сказать, что и откуда читать. Согласно документации .pgw, .pngw или .wld файл((Описание формата: http://www.gdal.org/frmt_various.html#WLD)) подтягивается автоматически, если на входе карта в PNG (про другие форматы - ниже), а вот .prj файл нужно читать самому. Для этого в последней версии GeoCrop сделана небольшая эвристика:
- Если растр содержит пустую проекцию, то производится попытка прочитать проекцию (формат WKT или PROJ.4) из файла с таким же именем, но расширением .prj и .prf.
- Либо файл проекции можно жестко задать при помощи новой опции
-p srs_def
Т.е. при наличии привязки в виде world files GeoCrop так же можно вызвать без дополнительных приготовлений так:
geocrop -f VRT -s 50k K-53-026-A.png K-53-026-A.vrt
если файл проекции находится в K-53-026-A.prj или K-53-026-A.prf, или так:
geocrop -f VRT -s 50k -p K-53-026-A.wkt K-53-026-A.png K-53-026-A.vrt
Обратите внимание, что в обоих случаях в качестве входного источника передаётся сам растр, а не его привязка.
Если у вас растры отличные от PNG:
- BMP - привязка ищется в .bpw, .bmpw или .wld.
- GIF - привязка ищется в .gfw, .gifw или .wld.
- TIFF - если это GeoTIFF со встроенной привязкой, то она и используется, если это просто растр, то привязка ищется в .tfw, .tifw/.tiffw или .wld, а так же в MapInfo .tab файле.
- JPEG - привязка ищется в .jgw, .jpgw/.jpegw или .wld, а так же MapInfo .tab файле.
Полный и актуальный список всегда можно посмотреть тут: http://www.gdal.org/formats_list.html
Global Mapper
В данный момент GDAL не поддерживает данный формат, а значит не поддерживает и GeoCrop. Ищите способ как сконвертировать его во что-то удобочитаемое.
Вообще .gmw файлы достаточно простые для разбора, так что, возможно, появится у меня и их поддержка. Тем более, что для тех же карт GGC там сразу зашита информация об обрезке (только странно, что они сразу не сделали рамку прозрачной).
Теперь в GeoCrop появился новый режим: генерация полигона для обрезки рамки в формате CSV+WKT. Вывод на stdout, так что можно сохранить в любой удобный файл из скрипта, после чего использовать как аргумент для -cutline
у gdalwarp в какой-то более сложной команде. Вызова gdalwarp при этом не происходит.
Активируется режим опцией -g
(от [g]enerate). Указывать выходной файл при этом не нужно - он будет проигнорирован.
Так же, теперь появилась возможность указывать файл с описанием проекции: -p srs_file
. Сама проекция должна быть в формате WKT или PROJ.4. Эта опция перезаписывает определение проекции в текущем файле. Полезна для преобразования файлов с привязками в виде world-файлов. Более того, если проекция в файле пустая, а опция не указана то произведётся попытка прочитать её автоматически из файла с таким же именем, но с расширением .prj или .prf (какой первый попадётся). Так что популярные карты ГГЦ с такими привязками теперь можно конвертировать так же просто, как и с привязками Ozi Explorer.
Чуть раньше реализована функциональность по передаче дополнительных параметров gdalwarp. Для этого нужно завершить опции приложения двойным минусом --
, опции после него будут переданы gdalwarp как есть без изменений:
geocrop -f VRT -s 200k K-53-07.map K-53-07.vrt – -overwrite
опция -overwrite
будет передана gdalwarp. Помимо этого, теперь можно переопределить и сам исполняемый файл gdalwarp - опция -w GDALWARP
.
Кроме того изменился формат опций, стало возможным указывать выходной формат (опция -f FMT
, как следствие, образовались такие возможности: post/2016/02/11/bystro_i_nenavjazchivo_gotovim_kartu_dlja_otkrytija_v_qmapshack) или только обрезать рамку, не делая кроп (опция -n
).
Внезапно QMapShack стал юзабельным!
Но немного истории. QMapShack это революционное развитие QLandkarteGT от того же автора. Просто архитектурно QLandkarteGT перестал соответствовать требованиям.
Итак, как минимум следующие фичи теперь доступны в QMS (принятая аббревиатура для QMapShack в расслылке)(((!) отмечены фичи уникальные, по сравнению с QLGT, а (-), то, что убрано, (?) - спорные изменения)):
- Открытие серии файлов с геоданными, переданных, как аргументы приложения. Это не относится с картам (?) - они берутся только из директорий, которые вы настроили в программе (аналогично произвольная карта не может быть открыта через File -> Open Map, такого пункта просто нет).
- Поддерживаются ВСЕ форматы карт, которые поддерживаются GDAL (!). Но делается это не напрямую, а через формирование .vrt файла. Сей унифицированный способ отменил отдельное открытие GeoTIFF - теперь нужно и для него формировать vrt-файл. К счастью теперь это делается через внутренний инструмент vrtbuilder и позволяет в большинстве случаев обойтись без утомительной конвертации в GeoTIFF, например привязок OziExplorer((В случае привязок Ozi, нужно открывать .map файл, в случае привязок .pgw+.prj открывать нужно одноимённую картинку))((К сожалению, на карты и привязки с http://loadmap.net он упорно ругается)). Вообще список теперь достаточно вменяемый:
- Векторые карты:
- .img - веркторные карты Garmin в non-NT формате. NT-формат не поддерживается и поддерживаться не планируется.
- Растровые карты:
- .vrt - враппер для всех типов GDAL.
- .jnx - Garmin Birds Eye.
- .rmap - CompeGPS Map Container
- Онлайн карты:
- .wmts - WMTSCapabilities.xml с любого картографического сервера, переименованный в уникальное имя. Дальше есть подробности.
- .tms - описание правил использования TMS серверов. Через такие файлы можно подключить всякие OpenStreetMap, OpenCycleMap и так далее. Встроенный мастер позволит сгенерировать такие файлы для некоторых популярных сервисов.
- DEM рельеф:
- .vrt - как и прочие растровые карты
- (!) Более развитые средства управления геоданными. Каждый файл GPX воспринимается как отдельный контейнер-проект. Данные между ними можно копировать. Теперь можно объединить несколько треков в один (!).
- (!) Больше информации по трекам: можно задать тип активности, можно посмотреть графики высоты от расстояния, скорости от расстояния, или прогресса пути от времени.
- (!) Более развитые средства редактирования треков. Правда точки так и не удаляются, но можно скрыть их, спрямив, например, трек (убрав топтание на месте, при остановке на обед или заделку колеса на велосипеде).
- (?) Более активное использование мыши в окне отображения карты. В контекстном меню находится большинство полезных пунктов, типа создания путевой точки или трека. Да и вообще больше динамики в интерфейсе, точнее в области карты.
- (!!!) Выделение, печать или сохранение произвольной области карты. Костыльное решение я делал для QLGT, но его не приняли. Там можно было распечатать только видимую часть карты.
А вот теперь каких инструментов не хватает в QMS, но есть в QLGT:
- Инструмент привязки карты по точкам (в визуальной форме). Не знаю, будет ли сделан, но таск завёл.
- Экспорт выделенного куска карты в JNX. Потребность сомнительная, но пару раз пригождалась.
Ну и ссылки:
Для примера будет рассмотрен сервис http://loadmap.net, который предоставляет карты с привязками в формате OziExplorer.
Минусом подобных карт бывает то, что у них есть рамка и отдельные листы карт перекрывают друг друга при открытии. Для того, что бы рамку резать я уже написал ранее((ozi2map от туда более не актуальна)) про свою программку geocrop.
Теперь про самый смак: QMS умеет открывать .vrt файлы. VRT файл это XML документ, с описанием привязки и различных преобразований, понятные движку GDAL. Так вот, в ходе беглого исследования оказалось, что мой способ резки рамки применим к VRT файлам: данное преобразование просто сохраняется внутри и применяется при открытии! Если добавить сюда тот факт, что переконвертации самого растра не происходит и просто формируется дополнительный маленький XML файл, то счастье становится полным.
Рассматривать вопрос сборки программы я подробно не буду, скажу только, что нужны dev пакеты для libgdal и libproj4. Устанавливать программу не нужно - просто скопируйте в удобное место, у меня это ~/bin
. Сборка и работа на Windows не проверялась.
Вот, преамбула завершилась… Основная часть будет короче :)
-
Скачиваем растровый файл карты, допустим это 500-метровка K-53-027-A, тогда файл будет K-53-027-A.png
-
Скачиваем файл привязки K-53-027-A.map
-
Обрезаем рамку и формируем VRT:
~/bin/geocrop -s 50k -f VRT K-53-027-A.map K-53-027-A.vrt
Обратите внимание на параметр -s - он задаёт масштаб листа в виде делителя, т.е. опущена 1:
, а буква обозначает степень десятки на которое нужно домножить: 50k (кило) = 50 * 10^3 = 50000 и масштаб тогда 1:50000, т.е. пятисотметровка.
//Их было четверо…
Они шли, шли, шли и, наконец, пришли!//
Наконец-то первый полноценный снегоступный ПВД за сезон. То несросты, то переносы, но всё-таки собрались: Я, Коля, Кирилл и Гена.
А вообще, пробую завести ещё одну традицию: снегоступинг на Читинзу во второй половине января или начале февраля. В прошлом году была первая серия.
Как обычно, выехали на первой электричке в субботу, домой возвращались на крайней в воскресенье.
Маршрут изначально намечали:
Партизан (пл.98 км) - руч.Просечный - С-В хребет - вершина 1156 м - трверс на Читинзу - Читинза - С-З хребет - р.Постышевка - Наречное.
Но в электричке скорректировали его до:
Красноармейский - Ручьи - С-С-В хребет (классика) - Читинза - траверс на Смольную - Смольная - С-В хребет - вершина 734 м - руч.Прав.Лесопильный - Тигровой
Небольшая сводка:
День |
Протопали, км |
Набор высоты, м |
Сброс высоты, м |
Время в движении, ч |
Средняя скорость, км/ч |
Начало движения, ч |
Конец движения, ч |
Cб |
16.9 |
1434 |
554 |
06:25 |
2.0 |
10:00 |
18:34 |
Вс |
14.2 |
201 |
1091 |
04:33 |
3.1 |
09:04 |
14:38 |
Всего |
31 |
1635 |
1645 |
10:58 |
2.8 |
— |
— |


Подкатом немного текста и фотографий.
Не могу не пропиарить цикл статей по управлению и устройству различных электродвигателей (ДПТ, АД, СД, всякие шаговики и так далее):
Да и вообще рекомендую блог к подписке: НПФ ВЕКТОР
Поражаюсь способности наших заграничных друзей давать всему свои термины, стоить под это целы ниши услуг и товаров. Чего только стоит:
- Гуляешь по парку? Пожалуйста - walking!
- Чуть сложнее? Да на здоровье - hikking!
- Уже несёшь дом за спиной? Всегда рады - backpacking!
- Идёшь в лыжный поход? Нет проблем - randonnee skiing (или ski touring)!
- Hillwalking, mountaineering, и так далее.
Под каждую нишу своё снаряжение, подготовленные тропы, гиды и так далее.
При чём тут снегоступы? Оказывается и для них есть свои названия:
- Наш жаргонный “снегоступинг” - это snowshoeing,
- а “снегоступер” - snowshoer.
В статье на Snowshoe|википедии
про это есть. Уж не знаю, существуют ли подготовленные снегоступные трассы, но если ответ положительный - я не удивлюсь :)
Хорошая статья на тему (автор - полярник):
Правда не знал, что -20, даже при ветре, это экстремально холодно :)
По способам: всё правильно. К примеру, дыхание ртом, когда язык загибаешь к нёбу. Про этот способ несколько лет назад сказал мой друг Олег. С тех пор и пользуюсь. Балаклава с “намордником” тоже решает. Правда скулы нужно не забывать закрывать, а то легкие не застудишь, а ряху обморозишь.
Кто не понял - название шутка. Привет Спайдеру :wink:
На воробей сходить никого сблатовать не получилось. Пришлось ноги напрячь, хотя бы где-то в районе города. Результат:
- Время: 6:15
- в движении: 5:06
- Километраж: 16.2 км
- Средняя скорость: 3.17 км/час
- Общий набор высоты: 1076 м
- Общий сброс высоты: 939 м

К слову сказать - до Острой не дошёл, но об этом дальше.
Пока LOG, Habrahabr и другие гудят по поводу смены лицензионной политики в части Qt (переход на LPGL3) и QtC (переход с LGPL2.1 на GPL3 /именно GPL/ с исключением для плагинов), у меня дошли руки обновить PPA: https://launchpad.net/~adrozdoff/+archive/ubuntu/qtcreator-git
Ну и несколько интересных (для меня) изменений, которые стали доступны в этом билде. Добро пожаловать под кат.
Пост-вопрос.
Может кто объяснить, почему в стандарт вошла настолько обрезанная версия реализации std::thread
? Ведь предлагаемый интерфейс не предоставляет абсолютно никаких средств передачи параметров потоку в момент создания, к примеру, тот же размер стека, что крайне актуально на всяких RTOS. При этом Boost.Thread такую возможность предоставляют средствами [boost::thread::attributes](http://www.boost.org/doc/libs/1_60_0/doc/html/thread/thread_management.html#thread.thread_management.thread.attributes)
:
template <class F>
explicit thread(attributes& attrs, F f);
template <class F>
thread(attributes& attrs, F &&f);
template <class F, class ...Args>
explicit thread(attributes& attrs, F&& f, Args&&... args);
Средства хоть и лимитированные, но доступ к native_handle атрибута позволяют тюнить параметры на конкретной платформе. Но в стандартной библиотеке нет и их. Нипанимать. Explain. Explain.
PS libstdc++ зато предоставляет достаточно простые средства, что бы добавить поддержку своих потоков (на той же RTOS), не прибегая к модификации кода библиотеки (если кому интересно, могу на пальцах разбросать как, но без полной реализации).
Добротное разъяснение (кому непонятно это и это (ну и по ссылкам отсюда)) категорий итераторов на ru.SO:
Intro
Статью изначально опубликовал на Хабре: http://habrahabr.ru/post/274179/
Дано:
- устройство с ARM926E-JS (Cypress FX3) на борту;
- находится на другом континенте;
- подключено (JTAG+USB+COM) к Linux компу;
- на комп есть SSH доступ (и больше ничего, только SSH порт).
Проблема: устройство нужно отлаживать и писать под него код. И делать это, желательно, удобно.
Решение с использованием OpenOCD, GDB и Qt Creator, а так же описание пути к нему, под катом.