23 февраля решили отпраздновать очередным снегоступингом.

По предложению Кирилла рассматривали варианты посещения южных отрогов Ливадийского хребта.

Маршрут изначально рассматривался как:

Фокино-г.Халаза-г.Горбуша-г.Лысый дед-Молёный мыс

но в результате был скорректирован до:

Душкино-падь Светланка-г.Круглая-г.Пидан-Лукьяновка.

Собралось три человека: я, Кирилл, Саня. В роли адового тропильщика в этот раз Кирилл.

Я подумал и решил, что функционала и стабильности достаточно для релиза версии 1.0.

Так что да будет так: https://github.com/h4tr3d/geocrop/releases/tag/v1.0

Если у вас на входе привязанный GeoTIFF, то проблем нет никаких, но если у вас просто растр (.png, .jpeg, .gif) и привязка для него, то есть нюансы. Вообще, GeoCrop умеет работать с любыми данными, с которыми умеет общаться GDAL. Но в в некоторых случаях не всё получается гладко, так, например, только сегодня он научился читать файл проекции для world-привязок (пара .prj+.pgw).

На просторах интернета можно встретить различные описания привязок, самые популярные:

• Ozi Explorer
• World files((http://www.gdal.org/frmt_various.html#WLD))
• Global Mapper рассмотрим более подробно.

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:

1. Инструмент привязки карты по точкам (в визуальной форме). Не знаю, будет ли сделан, но таск завёл.
2. Экспорт выделенного куска карты в JNX. Потребность сомнительная, но пару раз пригождалась.

Ну и ссылки:

• Сайт: https://bitbucket.org/maproom/qmapshack/wiki/Home
• Документация: https://bitbucket.org/maproom/qmapshack/wiki/DocMain

Для примера будет рассмотрен сервис http://loadmap.net, который предоставляет карты с привязками в формате OziExplorer.

Минусом подобных карт бывает то, что у них есть рамка и отдельные листы карт перекрывают друг друга при открытии. Для того, что бы рамку резать я уже написал ранее((ozi2map от туда более не актуальна)) про свою программку geocrop.

Теперь про самый смак: QMS умеет открывать .vrt файлы. VRT файл это XML документ, с описанием привязки и различных преобразований, понятные движку GDAL. Так вот, в ходе беглого исследования оказалось, что мой способ резки рамки применим к VRT файлам: данное преобразование просто сохраняется внутри и применяется при открытии! Если добавить сюда тот факт, что переконвертации самого растра не происходит и просто формируется дополнительный маленький XML файл, то счастье становится полным.

Рассматривать вопрос сборки программы я подробно не буду, скажу только, что нужны dev пакеты для libgdal и libproj4. Устанавливать программу не нужно - просто скопируйте в удобное место, у меня это ~/bin. Сборка и работа на Windows не проверялась.

Вот, преамбула завершилась… Основная часть будет короче :)

1. Скачиваем растровый файл карты, допустим это 500-метровка K-53-027-A, тогда файл будет K-53-027-A.png

2. Скачиваем файл привязки K-53-027-A.map

3. Обрезаем рамку и формируем 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 м - руч.Прав.Лесопильный - Тигровой

Небольшая сводка:

Подкатом немного текста и фотографий.

Не могу не пропиарить цикл статей по управлению и устройству различных электродвигателей (ДПТ, АД, СД, всякие шаговики и так далее):

• Векторное управление электродвигателем «на пальцах»
• Векторное управление для асинхронного электродвигателя «на пальцах»
• Электродвигатели: какие они бывают

Да и вообще рекомендую блог к подписке: НПФ ВЕКТОР

Поражаюсь способности наших заграничных друзей давать всему свои термины, стоить под это целы ниши услуг и товаров. Чего только стоит:

• Гуляешь по парку? Пожалуйста - walking!
• Чуть сложнее? Да на здоровье - hikking!
• Уже несёшь дом за спиной? Всегда рады - backpacking!
• Идёшь в лыжный поход? Нет проблем - randonnee skiing (или ski touring)!
• Hillwalking, mountaineering, и так далее.

Под каждую нишу своё снаряжение, подготовленные тропы, гиды и так далее.

При чём тут снегоступы? Оказывается и для них есть свои названия:

• Наш жаргонный “снегоступинг” - это snowshoeing,
• а “снегоступер” - snowshoer.

В статье на Snowshoe|википедии про это есть. Уж не знаю, существуют ли подготовленные снегоступные трассы, но если ответ положительный - я не удивлюсь :)

Хорошая статья на тему (автор - полярник):

• http://dave-aka-doc.livejournal.com/526452.html

Правда не знал, что -20, даже при ветре, это экстремально холодно :)

По способам: всё правильно. К примеру, дыхание ртом, когда язык загибаешь к нёбу. Про этот способ несколько лет назад сказал мой друг Олег. С тех пор и пользуюсь. Балаклава с “намордником” тоже решает. Правда скулы нужно не забывать закрывать, а то легкие не застудишь, а ряху обморозишь.

Кто не понял - название шутка. Привет Спайдеру :wink:

На воробей сходить никого сблатовать не получилось. Пришлось ноги напрячь, хотя бы где-то в районе города. Результат:

1. Время: 6:15
   1. в движении: 5:06
2. Километраж: 16.2 км
3. Средняя скорость: 3.17 км/час
4. Общий набор высоты: 1076 м
5. Общий сброс высоты: 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:

• http://ru.stackoverflow.com/a/479269/189892

Intro

Статью изначально опубликовал на Хабре: http://habrahabr.ru/post/274179/

Дано:

1. устройство с ARM926E-JS (Cypress FX3) на борту;
2. находится на другом континенте;
3. подключено (JTAG+USB+COM) к Linux компу;
4. на комп есть SSH доступ (и больше ничего, только SSH порт).

Проблема: устройство нужно отлаживать и писать под него код. И делать это, желательно, удобно.

Решение с использованием OpenOCD, GDB и Qt Creator, а так же описание пути к нему, под катом.