Простой способ изображения рельефа штриховкой в QGis

Простой способ изображения рельефа штриховкой в QGis

Изображение рельефа штриховкой — метод древний и многие считают его устаревшим. Но мало, ли для чего он может вам пригодиться? Например вы хотите замутить карту «под старину» или заполнить пустое пространство. А может вам вообще нельзя использовать растровую графику, а сделать векторную отмывку, о которой я недавно рассказывал, ресурсы не позволяют.

Неважно, по какой причине вы задумались о визуализации рельефа штриховкой. Важно то, что сделать это можно буквально в несколько шагов. Конечно же, если речь идет о простом оформлении, ибо штриховой способ оформления рельефа это искусство, ничуть не меньшее, чем расстановка подписей на карте.

Для начала возьмем любую демку, скажем SRTM:
растр SRTM

Через меню «Растр-Морфометрический анализ-Угол уклонов» преобразуем его в соответствующую протокарту:
Растр уклонов

Теперь векторизуем полученную картинку (Растр-Преобразование-Создание полигонов: растр в вектор). Это одна из самых ресурсозатратных операций, преобразующая каждый пиксель в полигон с присущими растру атрибутами.
Векторизация растра

Далее через меню Вектор-Обработка геометрии-Извлечение центроидов получим точечный шейп, который мы будем использовать в качестве слоя штриховки:
Центроиды полигонов

Теперь можно удалить все лишние слои и работать только с точечным шейпом. Все что нам нужно — задать стиль каждой точки, как черта, угол поворота которой зависит от атрибутивного содержания:
Задание угла поворота в QGis

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

Или подлжить под штриховку другой слой.
Рельеф штриховкой в OSM

Обратите внимание, что мы использовали штрихи одинаковой длины и толщины, а это значит, что на наш рельеф будет выглядеть однородным. В некоторых случаях, это может оказаться более выгодным решением.

Ну и самое главное. Никто же не обязывает использовать только один метод визуализации рельефа. Штриховка совместно с классической отмывкой смотрятся весьма неплохо и скрывают взаимные недостатки:

Визуализация рельефа по данным SRTM и ASTER GDEM в QGis+SAGA

Интро. В настоящей статье специально рассмотрен случай отображения рельефа для значительной территории по неоднородным данным о рельефе. В связи с этим, при работе с более простыми территориями, алгоритм может быть упрощен. Под визуализацией рельефа будем понимать создание растра отмывки и шейп-файла изолиний с атрибутивными данными о значении каждой изолинии.

В качестве показательной территории взяты Соликамский и Красновишерский районы Пермского края. В качестве подложки карта OpenStreetMap Mapnik Standart:
Соликамск и Красновишерск

Инструментом для работы послужит QGis 2.18.4 с подключенными алгоритмами SAGA. Все операции, связанные с фильтрацией и созданием изолиний можно выполнять как внутри QGis, так и запуская гис SAGA в качестве автономного приложения.

Рельеф на средне- и крупномасштабных картах в настоящее время в большинстве случаев отображается с помощью данных SRTM или ASTER GDEM, что связано с их глобальным охватом, открытостью и простотой получения. Разрешение этих данных (SRTM 90 м/пикс, ASTER GDEM 30 м/пикс) позволяет, при должной обработке, показывать особенности рельефа примерно до 15 зума. Несмотря на то, что данные ASTER точнее, их использование затруднено необходимостью дополнительной фильтрации для отсеивания значений, не отражающих реальный рельеф (например, высоты леса и жилой застройки). Оптимальных алгоритмов для такой процедуры, которые дают стабильный результат для значительной территории, не разработано, в результате чего, образец визуализации менее точных данных SRTM оказывается обычно более качественным как с геодезической, так и с художественной точек зрения. Однако, севернее 60° с.ш. и южнее 54° ю.ш. данные SRTM отсутствуют, что вынуждает в конечном итоге использовать оба набора данных при визуализации рельефа на территориях, выходящих за границы покрытия SRTM.

Наш случай именно такой (снизу данные SRTM, сверху ASTER GDEM):
ASTER и SRTM

Данные SRTM доступны из различных источников, из которых наиболее удобны сайты cgiar, gis-lab и viewfinderpanoramas. Я предпочитаю использовать последний, поскольку многие сцены там объединены и загружены сразу в geotiff-растры (обычно SRTM представлен в hdt-формате).

ASTER получить немного сложнее: сайты геологической службы США и NASA позволяют скачивать различные данные ДЗЗ, что требует от пользователя определенной подготовки. Кроме того, эти сайты иногда бывают недоступны, либо работают чрезвычайно медленно. В этих случаях можно скачать всю базу через торрент. Дополнительные источники получения данных SRTM и ASTER доступны на странице получения данных.

Помимо растровых данных, для работы нам потребуется шейп-слой с границами районов, который можно скачать с сайта gis-lab или загрузить с помощью overpass.

После того как исходные получены, можно запускать QGis:
ASTER и SRTM в QGis

Для начала объединим сцены ASTER в единый растр с помощью меню «растр-прочее-объединение»:
1объединение растров

В диалоговом окне укажем директорию со сценами и название итогового файла.
2объединение растров

Обратите внимание, что в некоторых версиях GDAL отказывается работать, если пути к файлам содержат кириллические символы. В моем случае все прошло успешно:
3объединение растров

Теперь сохраним полученный файл уменьшив его разрешение до разрешения SRTM. Если этого не сделать, в месте соприкосновения сцен из разных источников мы получим вот такую картину:
рельеф SRTM и ASTER

Выделяем в ТОСе наш ASTER, и через правую кнопку мыши вызываем диалоговое окно сохранения растра:
Сохранение растра в QGIS

Здесь обратите внимание на то, что-бы растр сохранялся как данные. Разрешение уменьшаем в три раза, т.е. вместо 18001 столбца вписываем 6000, а вместо 7201 строк вписываем 2400:
Сохранение растра в QGIS2

После сохранения растра он выглядит загрубленным, но все-равно более информативным, чем SRTM:
Сохранение растра в QGIS3

Большее сходство данным можно придать разнородной фильтрацией, однако этот вопрос мы здесь в должной глубине не затрагиваем. Дело в том, что отмывка обычно используется в виде почти прозрачного слоя-наложения и тщательное выравнивание разнородных данных для идентичности отмывки не всегда оправдано. Главная задача — сделать незаметной границу между данными, что зачастую, особенно на равнине, не представляет большой сложности. Разнородная фильтрация имеет смысл в основном для создания аналогичной насыщенности изолиний, о чем будет отдельно сказано ниже.

По той-же схеме объединим полученный растр с растром SRTM:
DEM-композит

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

image

Теперь необходимо отфильтровать наш растр или другими словами размыть его. Это не совсем тождественные понятия, но итоговый результат выглядит именно как размытие. Более подробно о различных типах фильтрации я пишу в соответствующей статье, здесь же рассмотрим вопрос практического использования простого фильтра.

Откроем панель инструментов в меню «анализ данных» и в списке геоалгоритмов SAGA-Grid-Filter выберем алгоритм «Простой фильтр»:

После нескольких минут обработки, алгоритм выдаст сглаженный растр:
отфильтрованный растр

Его мы и будем использовать для отмывки. С помощью меню «растр-морфометрический анализ-теневой рельеф»:

вызовем диалог создания карты теней:

На этом этапе следует знать одно неявное правило. В том случае, когда вы планируете использовать теневую отмывку в качестве подложки саму по себе, можно использовать значения по умолчанию. В том случае, когда ваша отмывка ложится на некую базовую карту (в нашем случае, такой картой служит OpenStreetMap), следует повернуть источник освещения на сто восемьдесят градусов. Дело в том, что стандартная отмывка представляет собой темный растр, который при наложении не только перестает читаться, но и зашумливает перекрываемые слои. Для того, что-бы это избежать, отмывку следует инвертировать, но в этом случае, горы выглядят как впадины, а каньоны напоминают холмы. Учитывая это, мы заранее изменяем источник освещения, что позволит нам при инвертировании сохранить визуальную форму отмывки. По умолчанию, источник освещения расположен в районе трехсот градусов, чего, конечно-же в природе почти никогда не бывает. Еще Салищев указывал на эту особенность — привычная отмывка рельефа обязана своему появлению лампам, которые обычно устанавливали слева от кульмана. Мы поменяем значение «300» на «120» и через несколько секунд алгоритм выдаст нам вот такой результат:

Теперь обрежем ту часть растра, что выходит за границы интересующих нас районов. Для этого выделим полигоны необходимых районов в шейп-файле и сохраним выделение в качестве отдельного файла.
Сохранение вектора

Через меню «растр-извлечение-обрезка»

вызовем диалог, в котором укажем исходный и результирующий растр и шейп-маску по которой будет произведена обрезка:

В результате получим вот такую картину:

Двойным кликом по полученному растру в ТОСе вызовем меню свойств, где сменим градиент с «от белого к черному» на «от черного к белому». После применения изменений растр инвертируется. В месте сочленения данных ASTER GDEM и SRTM осталась небольшая белая полоса, однако, после того как будет установлена прозрачность, а сама отмывка наложена на подложку, заметить эту полосу будет практически невозможно:

Для того, что-бы не инвертировать растр при каждой новой загрузке, сохраним его как новый слой, но на этот раз в меню сохранения отметим его не как «данные», а как «изображение». На этом создание отмывки закончено. Установим прозрачность отмывки 95% и подложим под нее OpenStreetMap:

Так выглядит чистая карта OSM:

А так выглядит карта OSM с наложенной на нее картой теней в районе соприкосновения данных SRTM и ASTER:

Процедуру создания изолиний мы специально усложним, дабы проиллюстрировать проблему, возникающую при визуализации рельефа на значительной территории.

Основная трудность при создании горизонталей в том, что для обработки больших растров не хватает никаких вычислительных мощностей. Растр приходиться делить, но процедура фильтрации, примененная к разным файлам приводит к тому, что изолинии на границе областей получаются разорванными. Особенно это заметно в случае, когда обработке подвергались сцены целиком — четкая линия небьющихся горизонталей видна даже при невнимательном рассмотрении. Исправить эту проблему простым способом нельзя, но можно сделать так, что-бы нестыковка изолиний не бросалась в глаза. Для этого следует разрезать первоначальный большой растр кривыми границами, в качестве которых замечательно подходят границы административные. Дополнительным преимуществом использования административных границ в качестве линий разреза является то, что при финальной компоновке карты они будут нанесены сверху, что еще сильнее замаскирует несогласованность изолиний.

С практической точки зрения эта проблема решается так. Создадим временный полигональный слой:
Новый временный слой2

Сделаем его редактируемым (иконка желтого карандаш), после чего установим режим добавления нового объекта
Редактирование в QGis

и обведем один из районов:

Сохраним фрагмент растра для этого участка (не фильтрованного растра, а исходного, мы же усложняем себе задачу!), обрежем его по обведенной области и отфильтруем с теми же параметрами, что и при создании отмывки. Затем с помощью геоалгоритма SAGA-Shapes-GRID-Горизонтали по ЦМР создадим изолинии через каждые 50 метров высоты.

Фильтрация не только убирает излишний шум, упрощая и выравнивая изолинии, но и позволяет «сцепить» наши разнородные данные. Вот пример извлечения изолиний из сырого растра:

Отчетливо просматривается линия сочетания данных ASTER и SRTM. При различных способах фильтрации растра ASTER GDEM эту линию можно делать более или менее заметной о чем я упоминал в начале данной статьи.

Изолинии из отфильтрованного растра на этот район выглядят так:

На границе растра изолинии замыкаются и не несут в себе географического смысла. Такие участки в последующем будут удалены. Именно поэтому обрезка dem-растра производилась нами не по границе района а по внешнему слою.

Аналогичные операции повторяем для второго района. Обратите внимание, что полигоны обрезки растра перекрывают друг друга:

Чем больше полигоны обрезки растров, тем дольше времени будет затрачено на обработку, но тем точнее будут соединяться изолинии:

После того, как изолинии извлечены, остается только обрезать их по контуру границ, сохранив оригинальные значения атрибутов изолиний. Для этого успешно применяется алгоритм «SAGA-Shapes-Lines-Пересечение линий и полигонов»:

Небольшая настройка стиля и изолинии готовы:

Обычная карта OpenStreetMap:

Тот же фрагмент карты, но с наложенной картой теней и горизонталями:

Отдельно необходимо вынести проблему неоднородности данных ASTER GDEM по качеству. Даже на нашем примере видно, насколько сильно артефакты отсутствующей и ошибочной информации сказываются на качестве визуализации рельефа в целом:

Данная проблема не имеет однозначного механистического решения. Наиболее оптимальные способы ее устранения зависят от требований к визуализации, выбранного региона и доступной вычислительной мощности. В качестве одного из способов решения я предлагаю использовать последовательное применение фильтра DTM (предельный уклон местности 10 градусов, радиус поиска 2 пикселя), заполнение пропусков в образованном в результате DTM-фильтрации растра (порог напряжения 10) и последующая фильтрация простым фильтром (круговой режим поиска, гладкий фильтр, радиус 5px). Этот метод не позволяет полностью избавиться от артефактов, но существенно снижает их число и сглаживает, что определенно положительно сказывается на визуализации рельефа:

Карта OpenStreetMap без отмывки и изолиний:

Карта OpenStreetMap с отмывкой и изолиниями:

Обильные фильтруации

Я вертел на имморалистическом хую все советы о том, как следует писать эти очерки. Но вы так часто просите меня фильтровать посты перед публикацией, что на этот раз я не сдержался и пошел у вас на поводу.

Буду фильтровать. Начну с фрагмента снимка SRTM:

Ну а хули елозить-то? Фильтровать — так фильтровать. К великой моей печали, вы в просьбах своих нихуя не говорите о предпочтительных способах фильтрации. Что-ж, поэкспериментируем, дабы никто не ушел обиженным.

Начнем с DTM-фильтра, в основе которого лежит статья Георга Фоссельмана. Технология фильтрации основана на предположении о том, что резкий перепад значений высоты на незначительном пространстве DEM-растра свидетельствует не об особенностях рельефа, а о наличии объектов местности, искажающих ЦМР. Проще говоря, если на левом пикселе высота десять метров, а на правом тридцать, то скорее всего на местности в данных точках вы вместо обрыва/карьера увидите стену леса, здание или другую нерельефную ебанину. Фильтр просматривает растр скользящим окном заданного радиуса и отделяет области с уклоном выше указанного. При соответствующих настройках, этот фильтр позволяет не только отделить неестественные превышения, но и разделить растр на слои равнин и уклонов.

На демке с территорией города Шахты, алгоритм фильтрации сбоит на терриконах и отвалах. Впрочем, на таких масштабах уместнее использовать вместо SRTM растры ASTER GDEM. На моем фрагменте все работает прекрасно. Вот вам равнины:

А вот уклоны свыше тридцати градусов:

Главное, помните фильтр только отделяет одни пиксели от других. Дать физическое объяснение результата — уже ваша задача. Вот какого хрена на острове Поперечном такие уклоны? Он же ровный как блин. У меня даже фоточка есть:

Чаще всего подобные искажения возникают за счет растительности. Отделить ее от рельефа практически невозможно. Но если на плакорах с этим можно почти смириться (нужно только забыть про разницу в возрастах, бонитетах, наличие дорог, лугов, болот и полей, ветровалы, бобров, пожары, рубки и усыхания), то получить детальную ЦМР для склонов долин обычно затруднительно. Да чего объяснять-то? Каждый из вас наверняка видел такую взаимосвязь растительности и рельефа:

Но хватит, уже про DTM. Вы можете подумать, что у меня нет чувства такта. Фильтр комочков (Filter clumps — да простят меня профессиональные переводчики) отсеивает связанные пикселы с единым значением, превышающие заданную площадь. Например, вот области в которых соприкасается не менее тридцати пикселов с единым значением высоты:

Мажоритарный фильтр (majority filter) делит растр на сегменты указанного размера. В каждом из них вычисляется значение большинства пикселов, которое впоследствии экстраполируется на всю область. В результате имеем следующее:

Исходный SRTM в приближении:

Результат работы мажоритарного фильтра в том же экстенте:

  • Для понимания, на рисунке ниже черные изолинии с SRTM наложены на красные изолинии с отфильтрованного растра. Результат налицо:

Морфологический фильтр, точнее фильтры. Спешу огорчить всех натуралистов. Умойтесь, к геоморфологии эти фильтры не имеют никакого отношения, даже несмотря на их специфические наименования. Базовых морфологических фильтров два: дилатация и эрозия. Кроме того, активно используются фильтры замыкания и размыкания. В первом применяется сначала дилатация, затем эрозия, во втором — наоборот. Нихрена не понятно? Не проблема. Вот вам иллюстрированная классификация. Основана на лучших моих художественных скиллах вкупе с простейшим графическим редактором:

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

Красные линии — горизонтали с растра дилатации, черные — горизонтали SRTM:

При эрозии происходит обратный процесс. Однородные области увеличиваются в размере за счет подавления шума между ними.

Красные изолинии с растра эрозии на фоне черных горизонталей SRTM

Это размыкание

с горизонталями

А это замыкание

с горизонталями

Все, хватит про морфологические фильтры. Это банально и скучно. Самое время испить из фрактальной реки и вспомнить про богов алеатики. Дамы и господа! Леди и джентельмены! Мудачье! Специально для вас, Карл Гаусс со своим фильтром!

— ээээээ, а где растр то?

А не будет растра. Ибо визуально после применения фильтра различия почти не отличить. Суть фильтра в отсеивании областей с заданным стандартным отклонением. Что-бы вы не расстраивались вот вам картинка с изолиниями (standart deviation = 1):

Фильтр Ли. Это к китайцам не имеет никакого отношения, просто я в душе не ебу, как перевести «Multi direction lee filter» на адекватный русский язык. Более того, я с трудом понимаю что это вообще такое, а для чего это — не понимаю вообще. Но раз уж зашла речь про фильтрацию, грех не рассказать про эту хрень.

Фильтр разделяет растр на три дочерних: результат фильтрации, растр минимума стандартного отклонения и растр направления минимума стандартного отклонения.

Результат фильтрации визуально от оригинала не отличим:

Минимальное стандартное отклонение. Тут все почти просто, если найти мануал, объясняющий значение прилагательного «минимальное».  Результирующий растр в псевдоцветах выглядит так (чем краснее, тем выше стандартное отклонение):

Слой изолиний в той же палитре:

Но самое интересное — направление минимума стандартного отклонения. Я воздержусь от комментариев, лучше покажу вам результат и выпью своего пива.

Изолинии по растру направления минимума стандартного отклонения на фоне изолиний SRTM (черные линии):

Гораздо понятнее обстоят дела с ранговым фильтром. Просто указываете ранг сатистики и извлекаете пиксели с нужными значениями. Вот, например, медиана

Изолинии из результата фильтрации (50-й ранг) на фоне изолиний SRTM:

На этом все.

Э, да я смотрю вас не наебешь. Действительно, а как же дивергенция градиента значений растра? Вообще физический смысл лапласиана достаточно условен, типа значений концентрации градиента. Но в нашем случае ситуация проще. Фильтр Лапласа выделяет контуры на растре. В итоге имеем следущее:

Да прибудет с нами псевдоцвет растра итогов применения фильтра Лапласа!

Ну и горизонтали, само-собой. Хотя, это все-таки не горизонтали, а просто изолинии.

Хотя, конечно, проще всего использовать простой фильтр. Особенно, если вы хотите строить горизонтали.

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

Надеюсь, на этом, ваша просьба о фильтрации полностью удовлетворена. Всем присутствующим спасибо. Все недовольные могут пройти нахуй, ибо тут у меня суверенный анархизм: хочешь с Бакуниным бухай, хочешь Вольтариану Де Клер еби. А советы ваши по поводу того, как мне следует статьи писать можете в жопу себе засунуть.

Рубкология

Весь нынешний август я шароебился по разным кустам занимаясь оценкой успешности лесовозобновления на сплошных вырубках юго-запада Ленинградской области. Суть работы сводилась к следующему: я вылезал из теплой машины под бесконечный дождь, цеплял к рюкзаку на манер навесного оборудования трактора обычную штыковую лопату, в «ливчик» комбинезона засовывал планшетку с бланками, сжимал посильнее рукоять здоровенного тесака для рубки медвежьих бошек и в позе супермена из армии Батьки Махно погружался в дремучий кустарник, где писал разную технологическую ебанину и вонзал в раскисшую землю сотни палок с красными лентами.
102_4624

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

Итак, друзья, тушите свет, зажигайте свечи, разбрасывайте по полу каштаны. Наливайте себе стакан до краев и располагайтесь удобнее, ибо во многом знании много печали, но памятуя про in vino veritas едва ли найдется тот, кто не заметит очевидного парадокса в измышлениях старинных мудрецов. Однажды придет и мой Мелет, сын Мелета, пифеец, но пока, дрожание рук походит на кривую судьбы Агриппины младшей, между Нероном и Тиберием велик соблазн немного повертеть на граненом стакане кровавый сапожок. Веселье, друзья, конечно же веселье служит нам путеводной нитью этого вечера! Все начинается с того, что раз в полторы недели вы до утра обрабатываете вымокшие бланки с кровавыми пятнами. Пеленг такой-то, широта такая-то, долгота такая-то, фото номер N. Три березы, две елки ноль пять, елка полтора, осина, две рябины, сосна ноль пять. Пишите, чертите, вслушиваетесь в свой голос с диктофона, просматриваете отснятые файлы. Что-бы не заснуть, выходите на улицу покурить и вновь возвращаетесь. Веселитесь изо всех сил.

102_4609

А через несколько часов, едва небо начнет светлеть, двери электрички закрываются и вы наслаждаетесь красотой и величием заоконных пейзажей:

102_3538
Чем дальше, тем пейзажи все красивее и величественнее
102_3523
И конечно-же, все веселее и веселее
102_3571

Но все проходит, стоит лишь выйти на пробу. Встанешь на первую вешку, оглянешь взором предстоящий фронт, сплюнешь и произнесешь благословенное «ёб твою мать». А из динамика телефона тебе отвечает лектор Петухов. «Давайте начнем!»: говорит он. А действительно, давайте начнем! И с этими словами ебнешь свою профилактическую соточку, затянешься поглубже чем бог послал и выпуская дым, начинаешь орудовать тесаком, вязать ленты, писать и бесконечно фотографировать.

102_4755

Прежде чем вы решитесь ввязаться в это дело, нужно понимать куда именно вам предстоит ехать. Как найти вырубки нужного типа леса, возраста, площади и транспортной доступности? Если вы сможете найти где-то карту с такими данными — честь вам и хвала. Но практика показывает, что самые ценные инструменты, для изготовления которых отводятся месяцы предполевых работ всегда приходится собирать в последний момент на коленке. Другими словами, нам нужно составить такую карту самому, иначе все у нас пойдет через жопу. Погнали?!

Карта рубок. Что есть рубки с точки зрения дешифрирования? правильно, рубки есть видоизмененный лес. Значит не ебем себе мозг, а прямо так, английским по белому пишем в поисковой строке браузера: «forest change map». По первой же ссылке попадаем на известный проект Global Forest Change:

111

Классная штука этот GFC. Спецы из Мэрилендского университета, Гугла и Геологической службы США, обработав огромное количество ландсатных снимков, выдали в качестве результата данные по изменению лесного покрова за период с 2000 по 2012 гг. Это то что нам надо, скачиваем данные на нужный нам регион в формате GeoTiff.

Теперь этот слой нужно разнести по типу леса, возрасту, площади и транспортной доступности. Сразу скажу, что первое — больше из области фантастики, ибо до тех пор, пока мы используем в качестве лесной типологии псевдонаучные фантазии времен раннего палеолита, никакой хитрый алгоритм применить не удастся. Да в этом и нет особой нужды, ибо как вы понимаете, основная доля всех рубок представляют собой кисличники, реже свежие черничники. Я бы на месте лесозаготовителей тоже всякого рода долгомошники вертел на харвестере, ибо рубль выберешь, рубль двадцать в гать утопишь.

102_4492

Но зато разбиение данных по остальным параметрам уже дело техники. Для начала векторизуем наш растр в QGis:

222

Из производного шейпа аттрибутивной выборкой по возрасту рубки извлекаем новый полигональный слой. Далее, через калькулятор полей считаем площадь каждого полигона, и удаляем слишком крупные и мелкие полигоны. Остается только исключить рубки, находящиеся в самых недоступных ебенях. Но это тоже не космос: скачиваем через overpass дорожную сеть OpenStreetMap, Строим вдоль проезжих дорог буферную область, доступную для пешего подхода и после этого удаляем все полигоны рубок, которые не пересекаются полученным буфером.

Все, слой готов. Экспортируем его в kml и  SAS.Планету, настроив подходящий вид:

333

Основной недостаток такого метода в том, что в выборку попадают рубки вытянутой и неправильной формы, совершенно неудобные для закладки учетных площадок. Кроме того, помимо рубок, встречаются еще естественные усыхания, пожары, ветровалы и подтопления. Последние, благодаря бобрам, особенно часто. Редкостные, скажу я вам, мудаки, эти бобры. Мало того, что эти пидоры столько леса хорошего затопили, так они еще и невкусные как водоросли. Их что жарь, что вари — все какая-то поебень получается.

Загружаем данные в навигатор и вперед — рубить ветки, месить говно и давить фиолетовые грибы

102_3089

Можно ли размещать площадки на волоках и в каналах? С одной стороны это тоже часть территории. С другой стороны, размещение учетных площадок в таких местах вносит не отслеживаемую погрешность. Вопрос можно поставить даже шире: уместно-ли рассматривать общие показатели восстановления для территории с комплексными видами нарушений? Правильно, неуместно. Пасеки — отдельно, волока — отдельно, земля — крестьянам, мудаков — нахуй.

102_4557Существует несколько принципов, которыми следует руководствоваться приступая к любым полевым работам. Конечно-же, следует помнить о нарастании коэффициента обалдевания: с каждым разом вы, вне зависимости от вашей старательности, будете выбирать наиболее легкие для описания площадки. Это неизбежно приводит к систематическому занижению результатов на 5-15%. Избежать этого можно путем формализации процедуры выбора точки описания: например подобно геоботаникам кидать дрын, служащий, после падения, стороной учетной площадки. Можно и протягивать на определенное расстояние рулетку по выбранному пеленгу. Но этот подход работает плохо даже на рубках трехлетней давности

102_3350

Как не вымеряй расстояние на вырубке по рулетке, все равно будет лажа. Либо закрадывается ошибка за счет изгибов рулетки, либо за счет пробики створов колоссально возрастает трудоемкость. Не ебите себе мозг, отмеряйте расстояние шагами, контролируйте себя по навигатору и не забывайте про коэффициент обалдевания.

Любые поточные полевые наблюдения кроют в себе опасность смещения данных. Стоит вам пропустить наблюдение на одной из учетных площадок, как ценность всех дальнейших наблюдений оказывается равной нулю. Но каждый раз заполнять чек-лист слишком затратно по времени. Поэтому мой вам совет: синхронизируйте все что только возможно. И немедленно. Если вы стоите на восьмой учетной плошадке, пусть номер вашей точки в навигаторе будет «508», а номер фотографии «18». Организуйте все так, что-бы пропущенное наблюдение моментально бы искажало конструкцию данных.

Нет ничего более тупого чем бесконечно записывать номера фотографий. Если вы синхронизировали нумерацию наблюдений, то вам стоит записывать только номера фотографий в точках контроля и номера ошибочно сделанных снимков. По завершению цикла наблюдений, просто суммируйте количество фотографий для дополнительной проверки. Ну и конечно же не забывайте про снимки-хуимки.

Очень часто люди не могут отделить фотографии одного ряда наблюдений от другого. Ну а хули, спрашивается вы фотографировали площадки на одной пробе, потом перешли через дорогу и не сделав ни одного лишнего кадра приступили к фотографированию площадок другой пробы? Естественно, потом при сортировке снимков приходится морщить ум и сравнивать время и содержимое кадра. Делайте проще, перед началом каждой пробы делайте несколько снимков-хуимков: фотографируйте какую-нибудь дичайше специфическую ебанину, например свой еблет, или рукав, или бланк с описанием. Помимо упрощения сортировки снимков, это позволит вам получить психоделический набор ебанутых фотографий для плаката «Я в двадцать пятый раз спрашиваю, что это за хуйня?»

hand

Стоит ли говорить о том, что на пробе вы записываете не количественные, а качественные показатели? Правильно не стоит. Потому что любые количественные измерения есть суть более формализованные качественные. И если в одной графе бланка записано «87 берез», а в другой «92 березы», только безумец будет утверждать, что во втором наблюдении на пять берез больше. Разумный человек сразу понимает, что на обоих площадках одинаковое количество подроста, чуть меньше сотни стволиков, но определенно больше полусотни. И во втором наблюдении их может оказаться чуть больше, хотя если подсчитать, может и чуть меньше. «А чего-же не подсчитать их точно?» — спросит какой-нибудь далекий от биометрии человек. А подсчитать их точно невозможно, ибо натуральные числа используемые для счета представляют собой слишком грубый инструмент, не позволяющий описывать переходные состояния. Каждый стволик считается по отдельности, но в какой момент растущий стволик отличается от новой ветви, особенно если речь идет о корневой поросли? Нет, коллеги, натуральный счет тут не подходит, да и действительные числа едва ли применимы. Я уж не говорю о космической сложности таких измерений.

102_4321

Нахрена столько сложностей в подсчете кустов? А сложностей никаких и нет. Рост профессионального геоботаника составляет один метр семьдесят восемь сантиметров. Поэтому для определения количества подроста на гектар, ему достаточно сосчитать количество стволов, на которые он упадет если выпьет на стакан больше положенного и умножить полученный результат на тысячу. Причем, поскольку упасть он может в разные стороны, подсчет стволиков ведется на всей площади круга, радиусом 1,78 м. Обернулся вокруг себя — видишь, что при падении непременно подомнешь под себя три елки и пять берез. Следовательно, на гектаре три тысячи стволов елового подроста и пять тысяч подрастающих берез. Если вам трудно представить, как вы пьяный валяетесь по кустам или ваш рост далек от идеала, можете крутить вокруг себя рейку аналогичной длины, а еще лучше приспособьте для этого дела телескопическую удочку. Впрочем, навык приобретается быстро.

В чем же секрет? Да все просто: Pi*r^2 => 3.14*1.78*1.78 ≈ 10 кв. метров. Гектар есть 10 000 кв. метров, а следовательно наша круговая площадка есть тысячная часть гектара.

Гораздо сложнее определять не количество, а возраст подроста. Если у сосны еще можно быстро подсчитать количество мутовок, примерно соответствующее числу прожитых лет

102_4702

то с елкой уже сложнее, мутовки у нее выражены гораздо хуже

102_4754
А у лиственных вообще хрен возраст определишь. Разве что по числу побегов или годовым кольцам, но все это разовые замеры. Обычно прикидываешь зависимость возраста от высоты для нескольких модельных стволиков, и далее интерполируешь сотни и тысячи наблюдений.  Ценность таких данных сами можете себе представить. С другой стороны, разве можно получить бессмысленные данные иначе как занимаясь бессмысленным делом?

Очередной день рождения молодой березки — место нарастания нового побега.

108_5032

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

108_4994

И делаете так:

108_4995

Еще раз продемонстрирую. Подходите к дереву:

108_5026

Хуяк!

108_5028

А далее руководствуетесь вот этой схемой определения жизненного состояния:

shema

При планировании подобных исследований, особое внимание следует уделить времени проведения работ. В условиях Северо-Запада Русской равнины, сплошные рубки обычно приводят к повышению уровня грунтовых вод. Конечно, если вам предстоит работать преимущественно в скальных, лишайниковых или брусничных типах то все ок:

102_4673Но скорее всего, вам придется обследовать долгомошники, черничники и кисличники:

102_4757

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

Не всегда разумно идти к рубке кратчайшим путем. Ведь срубленный лес как-то вывозили, а значит к любой рубке идет дорога. В каком она состоянии это уже отдельный вопрос.

102_4555

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

102_4583

С другой стороны «полное отторжение от бреда нашего» вам гарантировано. Да и как может быть иначе в условиях, когда последние мировые новости узнаешь из лесохозяйственных столбиков?

108_4996

Да, дожди утомляют, но с другой стороны комаров и клещей мало. Зато много грибов, а брусники вообще как говна:

102_4553

И все же мне сказочно повезло. Окончание лета я встретил в Сланцевском районе. Дожди прекратились на целую неделю и все живое выползло погреться и просохнуть перед наступлением первых холодов.

Вылезли кистехвостки (Orgyia antiqua):

102_3369Вылезли семиточечные божьи коровки (Coccinella septempunctata):

108_4790

и разная другая живность

108_5033

Только гадюк стало гораздо меньше — весь август они ползали под ногами, что довольно сильно меня напрягало ибо змей я панически боюсь с раннего детства. Глядя на всю окружающую красоту, просто нельзя было не вспомнить, что даже живущий один год жук-навозник умеет ориентироваться по звездам, а я за четверть века так ничему и не научился.

dscn9008

Зато каждый вечер после работы, я выбирал наиболее живописное место, собирал дрова, набирал из ближайшего ручья или лужи воду, любуясь попутно великолепным закатом.

108_4964

Темнота стала наступать гораздо быстрее чем в начале лета. Я укладывал на свою лежанку рюкзак, разводил костер и устраивался поудобнее.

108_4905

Подогревал себе фасоли в помидорном соусе, кипятил крепкий чай и наливал маленькую рюмку водки

108_4907

После, выпив и закусив, откидывался на спину и закуривая, посылал огоньком сигареты сигналы в самые глубины млечного пути. У меня была своя маленькая программа «SETI» и звезды охотно мерцали мне в ответ. Так я и засыпал, без всякой палатки, укрываясь на ночь исключительно звездным небом. Утром меня ждал новый маршрут, днем — новые обследования, а вечером — новый уютный костер.

Однажды утром я проснулся от холода. Костер погас, ветер гнал кучевые облака и спешить мне было некуда. Лето закончилось, а вместе с ним завершились работы по оценке лесовозобновления на вырубках. Мне пора было возвращаться обратно — до конца полевых работ оставалось менее полутора месяцев. Вскипятив себе чаю я собрал свой нехитрый скарб и закопав кострище, направился в сторону ближайшей дороги.
108_5040

Пивопровод на ХБК

В поселке ХБК сто четыре жилых дома, которые необходимо подключить к пивопроводу. Само собой, сделать это необходимо с минимальными издержками на прокладку труб и дальнейшее их обслуживание.

Для проектирования пивопроводной сети, откроем в QGis карту OpenStreetMap с помощью плагина QuickMapServices или его старого аналога OpenLayersPlugin:

1

Приблизим интересующий нас район, и создадим полигональный шейп-файл:
2

Обведем контуры поселка:
3
Теперь, требуется загрузить контуры домов, нуждающихся в подключении. В нашем случае самым простым решением будет импорт зданий из базы геоданных OpenStreetMap с помощью сервиса Overpass turbo. Мы для этих целей воспользуемся плагином QuickOSM, загрузив полигональные объекты со значением «building=apartmens». В OSM полигонального типа нет, модуль выполняет эту конвертацию за нас:
4
В результате получим векторные слой, который будем использовать для построения графа.

5

Прежде всего, получим вершины графа, путем извлечения центроидов полигонов:
6
Если бы мы располагали графическими картами в качестве исходного материала, то пришлось бы их отсканировать, затем привязать, затем оцифровать. Это конечно дольше, но мы бы расставили точки более сложным образом. Центроиды полигонов хорошо применять только в случае простых полигонов, на сложных это приводит к погрешности:
8
Впрочем, нас такая точность устраивает, тем более, что от каждого центроида будет идти разводящая сеть. Мы получили вершины графа. Теперь, используя триангуляцию Делоне создадим множество полигонов, каждая вершина которых будет точкой центроида зданий.
7
Преобразуем полигональную триангуляцию в сеть линий. С помощью команды «split» плагина Networks разобьем сеть на отдельные линии. Мы получили граф, достаточный для роутинга. Если нам потребуется кратчайшим образом связать между собой две его вершины, достаточно будет просто использовать модуль RoadGraph:
9
При необходимости, можно добавить каждому ребру графа определенный вес. Полученные полилинии можно экспортировать в виртуальный слой и во внешний шейп.
15

Но у нас немного другая задача — построить сеть с ребрами минимальной длины. Для этого рассчитаем длину каждого ребра, используя встроенный калькулятор QGis:
13
Раскрасим слой ребер по градиенту возрастания длины ребра.
14
Ребер у нас много, поэтому выведем длину каждого из них в качестве подписи:

4

Теперь начинается чистая математика: нам требуется выбрать наиболее подходящий алгоритм. Очень много зависит от конкретных условий проектирования, например нельзя оставлять висячие ребра, нельзя делать множественное ветвление и др.

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

Добавим домики, отметим точки ветвления сети, изменим для лучшей визуализации проекцию и схема готова.

2

Теперь, зная длину каждого участка, формулу прогиба труб, значения износа и сложности монтажа, мы можем рассчитать затраты на строительство пивопроводной сети.

Формат FRNP: назначение и спецификация

Друзья мои, однажды, когда я работал редактором в одном научном журнале, мне довелось описывать историю создания программы для обработки геоботанических данных. Чуть позже, эта статья в популяризированном виде была выложена на Хабр и, вполне может быть, присутствует там до сих пор.

Хочу читать статью тут

Софт, формат, стандарт и немного занудства — опыт разработки программы для обработки геоботанических данных

В студенческие годы я пошел по наклонной и стал ботаником. Да-да, самым настоящим, который рвет «траву и лишаи», а после сидит с тяжеленными определителями. И хоть это не стало основным видом моей деятельности, но все-таки часть ботанической (точнее геоботанической) работы мне досталось. Под катом — взгляд на работу геоботаника с позиции айтишника, выраженный через опыт разработки костыльного софта. Обращаю ваше внимание, что слова «работа геоботаника» и «взгляд айтишника» расположенные в одном предложении означают, что дальнейший текст противопоказан беременным, несовершеннолетним, а также людям с неустойчивой психикой и сердечно-сосудистыми заболеваниями.

 

«Кто такой Тайлер Дёрден?»

Меня часто спрашивают, знаю ли я Тайлера Дёрдена кто такие геоботаники? Отвечаю: геоботаники — специалисты по растительным сообществам. В отличии от, например, систематиков, которые путешествуют из одной пыльной гербарной в другую, геоботаники свой материал собирают исключительно в поле, составляя геоботанические описания — специальные таблицы, в которых указано какие растения и в каких объемах произрастают на площади. По этим таблицам в дальнейшем можно определить показатели плодородия и влажности почвы, антропогенную нарушенность, кормовую ценность участка и много других интересных вещей. И, как вы понимаете, это определение ведется так же как и в эпоху, «когда динозавры были маленькие» — с бумажным бланком и миллиметровкой. Самые продвинутые используют Excel.

 

 

«А теперь, Горбатый!»

Перефразирую Жеглова: «Геоботаник, который вносит данные из бумажного бланка в Excel, зря получает рабочую карточку». И дело тут вовсе не в экселе. К этой программе претензий нет — вещь замечательная, к тому же тотально перекраденная, с доступной portable-версией. И даже то, что формат xls не ГОСТовский, не только не беспокоит, но даже неизвестно основной массе специалистов. Основная проблема перевода с бумажных бланков в табличные редакторы состоит в бесполезности этой работы. Чем плохи экселевские таблицы? Вот вам аналогия с книгами: лет пять назад я начал активно собирать коллекцию из отсканированных pdf и djvu версий книг. За годы коллекция разрослась до сотен гигабайт, и пожалуй единственного чего в ней нет это пользы. После определенного момента, я полностью перестал пользоваться этими книгами, поскольку времени на поиск информации в моей библиотеке уходило больше чем на поиск такой информации в интернете. Форматы электронных книг хороши для художественных романов на ридерах, но для хранения технической литературы подходит только сеть и никак иначе. От того, что «Флора СССР» отсканирована, она не станет более востребованной чем ботанические разделы Википедии.

То же самое с геоботаническими описаниями. Работая по проекту восстановленной циркумбореальной растительности я собрал небольшой электронный фитоценарий (коллекция геоботанических описаний) — в несколько сотен описаний, в наивной попытке обработать его. Тут требуется отметить, что описания в фитоценарии были сделаны в разных природных зонах, разными авторами, в разное время, разными методами. Такие описания принципиально невозможно стандартизировать и сравнивать, если конечно речь не идет о грубом качественном сравнении («тамо были лишаи, а тамо мохи и евоные ягоды»). Даже работа, по формированию единой базы данных на основе этих описаний мучительна и уже потому неправильна.

 

«Надо понимать всю глубину наших глубин!»

Да, я опять нудю (или нужу?) об отсутствии стандартов и нелепости современной геоботаники. Это Леонтий Раменский мог позволить себе собрать десятки тысяч описаний и вручную их обработать. Сегодня это невозможно — никому не нужны такие работы, даже при том, что реально увеличить производительность за счет технических средств. Поэтому, если мы хотим работать с крупными фитоценариями, необходимо объединять наработки каждого в единую базу. Но для этого следует хотя-бы оформлять описания по единым стандартам, а не как придется. Да, я конечно понимаю, что «научная» полевая работа — это сегодня очень часто не более чем оплачиваемые турпоездки. Потому и не ставится вопрос об единых стандартах и методах. Потому и не поднимается вопрос о целесообразности публикаций описаний в журнале «Растительность России» (за публикацию таблиц описаний в БУМАЖНОМ журнале уже давно пора давать орден «почетный старпер»). Однако же, на дворе 21 век, а геоботаники продолжают заполнять бумажные бланки собственного изобретения.

 

«Это вам не это!»

Первую попытку оптимизировать работу с «сырыми» описаниями я предпринял три года назад в рамках работ над программой PhytoSoft (разработка велась в Borland C++ Builder 6). На тот момент, стояла задача облегчить и ускорить ввод данных с полевого бланка, для последующего анализа по экологическим шкалам Л.Г. Раменского (помните, я выше говорил о том, что с помощью геоботанических описаний можно определять плодородие и влажность почвы? Это, как раз и есть «метод экологических шкал»). Программу удалось довести до работоспособного состояния, но при крайне низком бюджете, она так и осталась на этапе альфа-тестирования и позже была выложена в открытый доступ со всеми своими тараканами.

Сейчас я понимаю, что концепция «Фитософта» содержала в себе несколько ужасных стратегических ошибок. И дело даже не в том, что код — говно и руки растут из того же места, что и ноги. Сама идея того, что следует упростить ввод описаний с бланка в корне неверна. Во время показа первой успешно скомпилированной версии, я регулярно слышал вопрос, о возможности импорта в Фитософт описаний из Excel. Несомненно, я при разработке предусмотрел такую возможность, но технология импорта была уродской и я всегда старался замолчать этот вопрос, хотя он был и остается одним из главных. Даже если сейчас, появится чудо-программа для геоботаников, что делать с теми описаниями, которые уже введены в табличные редакторы? Выше я сказал, что привести описания разных авторов к единому шаблону практически невозможно, соответственно, у каждого описания будет либо собственная структура, либо общая структура будет сверх-сложной и всегда найдется описание, которое в эту структуру не встраивается. Требовался принципиально иной подход к организации данных в описаниях, чем те к которым мы привыкли (строчки-колонки).

Формат *.gbo который использован в Фитософте под эту задачу никак не подходил. Я не оформил должным образом спецификацию на него, но самое главное, что он тоже представлял собой те самые «строчки-колонки». Проще говоря, «*.gbo» — это большущая таблица, высотой в тысячу строк, шириной в несколько сот колонок. Каждое описание в таблице занимает одну строку. Описание разбито на логические элементы, которые размещаются в разных ячейчах. Например, в пятой ячейке первой строки указан автор первого описания, в шестой ячейке первой строки указана дата первого описания и т.д., в пятой ячейке второй строки указан автор второго описания, в шестой ячейке второй строки указана дата второго описания и т.д… Логика формата очень проста, но для импорта внешних файлов, последние приходилось мучительно переделывать (представьте: вашу сводную таблицу описаний необходимо перестроить таким образом, что-бы с 50 по 100 колонку шли названия видов, а с 101 по 151 их проективные покрытия). Эта проблема возникла от того, что вместо разработки программы под формат шла разработка формата под программу.

 

«Это не кадка, а настоящее японское фураке!»

Может быть я изобрел велосипед, но зато на собственной шкуре понял, что программное обеспечение и формат файла это никак не связанные (в плане разработки) вещи. Изначально следует разрабатывать формат файла, причем делать это независимо от того, когда и кем под этот формат будет написано программное обеспечение. После этого уже имеет смысл писать программу. При этом, придется решать многие задачи, которые не возникли бы при создании формата «под себя», но с другой стороны, риски того что формат будет обладать критическими недостатками снижаются.

Вот конкретный пример. Если вы изначально разрабатываете формат, как отдельный проект, то наверняка учтете, что он должен быть приспособлен для импорта в ГИС. После этого, начав разработку, вы будете вынуждены решать проблему с ГИС-совместимостью, даже если геоинформационными системами в вашей программе и не пахнет. Зато от этого формата не откажутся, что неизбежно произошло бы, когда выяснилось, что формат бесполезен для ArcGIS, QGIS или другой программы.

Формат файла должен быть максимально удобным для конвертации в другие и из других форматов.

Разрабатывая Фитософт в рамках идеи упрощения оцифровки бумажных бланков я ошибался. Бумажных бланков не должно быть вообще, полевые данные сразу должны быть готовы к обработке. Но, поскольку любой тупиковый путь рано или поздно заканчивается, примененная концепция довольно быстро изжила себя, породив новую проблему. С одной стороны, стало ясно, что геоботаник должен вводить данные в программу сразу после их получения в поле. С другой стороны, это означает, что он не будет пользоваться ни компьютером, ни ноутбуком. Планшеты? Но их цена столь же аморальна, как и срок заряда батареи. А самое главное, я вспомнил, в каком состоянии возвращаются полевые бланки — намокшие, с пятнами крови от раздавленных комаров. И со стороны пользователя я бы не хотел, что-бы моя (и не только моя) привычка не задумываясь бросать планшетку (которая скрепляет бумажные бланки) рядом с собой погубила однажды электронику. Планшет не подходил. Оставался смартфон. С точки зрения пользования это идеальный вариант — стоят они гораздо меньше, берут их с собой в любую погоду и вероятность повредить их гораздо меньше. Но в то же время это значит, что весь код, связанный с интерфейсом Фитософта можно удалять. Для полевых условий требуется что-то принципиально иное чем множество окон выбора.

 

«Айл би бэк»

Вопрос организации нового интерфейса долгое время казался тупиковым и в настоящее время нет еще полной ясности в некоторых деталях. По мере проработки формата, становится очевидно, что он должен быть максимально простым и компактным. Насколько я представляю, это должно быть нечто сходное командной строкой. Что же касаемо формата, то я считаю самым разумным отказаться от табличной организации данных в пользу HTML-подобного метаязыка. С одной стороны, это позволит легко восстанавливать табличные структуры описаний, с другой стороны, уже введенные в табличные редакторы описания гораздо проще приводить к стандарту, путем добавления соответствующих тегов.

Данный пост посвящен описанию HTML-подобного метаязыка для работы с геоботаническими данными. Поскольку вы такая ленивая жопа, что не стали читать приведенную статью и не уловили мой месседж, сообщаю: в нынешний технологический век, когда даже фаллоимитаторы имеют встроенный компьютер, работать в поле методами Александра Гумбольдта это, право, моветон или, переводя с французского, западло.

Когда геоботаники гордятся своей экселевской таблицей описаний, у меня глаз дергается. Потому что, любому контролеру в электричке известно, что информация делится на содержание и контекст. Данные и мета-данные это те же яйца, только в другой терминологический профиль. Информация имеет ценность только при наличии метаданных. Без них нет информации как таковой.

Что же делают геоботаники? Они берут бланк и переносят его в табличный редактор, в надежде, что чудо-компьютер предоставит им бесконечное количество инструментов для анализа. А когда выясняется, что таким образом никаких новых данных не получить, разводят руками, мол, фуфло все, эти ваши компьютеры: разве что миллиметровку экономят.

Когда геоботаническое описание написано на бланке, мы связываем данные с их контекстом по взаимному расположению записей. То же самое происходит, когда данные перенесены в таблицу экселя. Для того, что-бы машина работала с информацией, ей необходимо явно указать связь данных с их контекстом. Без этого невозможна даже примитивная выборка и сравнение данных, не говоря уже о более сложных вещах. Если не верите, то попробуйте решить следующую задачу:

«Из пяти множеств описаний отобрать те, для которых коэффициент Жаккара более 0,7 если в них присутствует группа таволги и коэффициент от 0,4 до 0,7, если в них доминируют луговые виды»

Представили себе объем работы? Ну, тогда хера ли мы с вами рассуждаем о всякой банальщине, ловите истинную суть этого поста:

=======================================================

Формат FRNP, версия 1 (Voikar)

Формат FRNP (format research nature page) предназначен для хранения и автоматизированной обработки данных о растительности, почвах и отобранных образцах, полученных в ходе полевых работ.

Синтаксис
В нотации Бэкуса-Наура:
Char ::= ‘A’|’B’| … |’Z’|’a’|’b’| … |’z’|’%’|’№’|’0’ | ‘1’ | ‘2’ | … | ‘9’|’_’|’+’
Note ::= ‘A’|’B’| … |’Z’|’a’|’b’| … |’z’|’%’|’0’ | ‘1’ | ‘2’ | … | ‘9’|’_’|»’|’,’|’.’|’%’|’№’|’@’|'(‘|’)’|’+’
Text ::= ‘»‘
Polychardelimited ::= ‘,’
Delimited ::= ‘:’
End ::= ‘;’
String_end ::= ‘$’
Name ::= {Char},Char
Data ::= {{Text,Note,Text}|{{Char},Polychardelimited,{Char},Polychardelimited},{Char}
Descriptor ::= {Name,Delimited,Data,End}String_end
Base ::= {Descriptor}

Семантика
Пробелы и символы переноса строки игнорируются.

Приставки и окончания:
total — общее (например общее проективное покрытие);
% — показатель измеряется в процентах;
1,2…10,… — показатель измеряется в долях от 1,2…10,…;
quality — качество;
№ — номер;
sp. — вид;
c — окружность;
sm — показатель измеряется в сантиметрах;
h — высота;
m — показатель измеряется в метрах;

Корни:
dendro — древесный ярус;
underdendro — подрост;
upgrass — подлесок;
grass — травы и кустарнички;
undergrass — мхи и лишайники;

Дескрипторы описания:
tags — ключевые слова (теги) описания;
time — дата в формате ГГГГММДД, например седьмое июля 2015 года: 20150807;
author — автор или авторы описания;
feedback — контакты для связи с автором;
license — лицензия распространения данных;
source — источник данных;

Дескрипторы местоположения
lat — широта;
long — долгота;
ele — высота над уровнем моря;
datum- система координат:
wgs84 — WGS-84;
pulkovo42 — СК-42;
unknown — Неизвестная система координат;
area — площадь описания в квадратных метрах;
note- примечание;

Дескрипторы описания древостоя:
totaldendrocover% — общая сомкнутость древостоя в процентах;
dendrocover% — повидовая сомкнутость древостоя в процентах;
dendroshare10 — состав древостоя в долях от десяти;
dendrocompleteness — абсолютная полнота древостоя в квадратных метрах;

Дескрипторы описания подроста:
totalunderdendrocover% — общая сомкнутость подроста в процентах;
underdendrocover% — повидовая сомкнутость подроста в процентах;
underdendroquality3 — состояние подроста в трех баллах (1-нормальный, 2-удовлетворительный, 3-угнетенный)

Дескрипторы описания подлеска:
totalupgrasscover% — общая сомкнутость подроста в процентах;
upgrasscover% — повидовая сомкнутость подлеска в процентах;

Дескрипторы описания травяно-кустарничкового яруса:
totalgrasscover% — общее проективное покрытие травяно-кустарничкового яруса в процентах;
grasscover% — повидовое покрытие травяно-кустарничкового яруса в процентах;

Дескрипторы описания мохово-лишайникового яруса:
totalundergrasscover% — общее проективное покрытие мохово-лишайникового яруса в процентах;
undergrasscover% — повидовое покрытие мохово-лишайникового яруса в процентах;

Дескрипторы описания почв:
soil(N) — номер почвенного горизонта верху вниз (soil0,soil1,soil2 и т.д.);
Шаблон значения дескриптора описания почв
m_colorsoil_density_composition_root_stone_coal
m — мощность горизонта;
colorsoil — цвет почвы по А.С. Захарову (например светло серый — «white-grey»)
composition — механический состав горизонта:
cl — глина;
hl — тяжелый суглинок;
ml — средний суглинок;
ll — легкий суглинок;
sl — супесь;
sd — песок;
density — плотность горизонта:
f — слитой;
t — плотный;
p — уплотненный;
c — рассыпчатый;
l — рыхлый;
root — наличие корней;
stone — наличие камней;
coal — присутствие углей;
peat — торф;

Дескрипторы описания отобранных образцов:
dendroextruder№_sp._csm_hm — отобранный образец дерева с указанием номера, вида, окружности и высоты дерева;

Пример описания:
tags:»betula»;
time:20150807;
lat:66.00287;
long:63.66359;
ele:58;
datum:wgs84;
note:
«Описание №102. Склон 3 градуса ЮВ экспозиции с кочками высотой 0,4 м»;
totaldendrocover%:40;
dendroshare10:
picea_obovata_4,
betula_aurata_6;
dendroextruder№_sp._csm_hm:
248_picea_obovata_71_13,
249_picea_obovata_71_14,
280_betula_aurata_53_13;
totalunderdendrocover%:5;
underdendro:
picea_obovata,
betula_aurata;
totalupgrasscover%:5;
upgrasscover%:
sorbus_sibirica_1,
duschekia_fruticosa_3,
rosa_accicularis_1;
totalgrasscover%:80;
grasscover%:
vaccinium_myrtillus_70,
ledum_palustre_7,
carex_globularis_1,
vaccinium_vitis-idaea_1,
licopodium_sp._3,
linnea_borealis_+;
totalundergrasscover%:40;
undergrasscover%:
pleurozium_schreberi_30,
ptilium_crista-castrensis_10,
politrichum_commune_5,
sphagnum_sp._+,
hylocomium_splendens_+;
soil0:
13_peat;
soil1:
6_white-grey_cube_l_sd_stone_;
soil2:
brown_cube_плотн_sd;
$

=======================================================

Да, я знаю, что описанная спецификация содержит косяк на косяке, но надо же хоть с чего то начинать. Кстати, если по Бэкусу-Науру есть специалисты, ткните меня пожалуйста носом в косяки оформления синтаксиса. Пока я вижу только то, что запись Data типа ___,____,_____ будет считаться допустимой. Это не очень хорошо, но приемлимо.

Мапим по гуглопанорамам — наземное фотограмметрическое картирование в QGIS с помощью плагина stereoSurveys

Read in English

Замечание 1. В данной статье не расматриваются юридические вопросы законности использования описанного метода при работе с данными компании Гугл. Мое дело метод показать, а с юристами сами разбирайтесь.
Замечание 2. Собственно, ничто не мешает использовать любые другие данные, вплоть до своих фотографий.
Замечание 3. Код описываемого ниже модуля от первой до последней строки написан Enrico Ferreguti. Мое значение в этом проекте чисто терапевтическое.

Пару месяцев назад я опубликовал пост о технологии применении снимков Google StreetView для фотограмметрического картирования территории. Этот незатейливый текст вдохновил Enrico Ferreguti (по его словам) на разработку модуля StereoSurveys для QGIS.

Основное назначение модуля — перенос контуров объектов, попавших в объектив камеры гугломобиля в точечный слой QGis. Наличие объекта с известным пеленгом на двух геопривязанных снимках позволяет однозначно установить его местоположение по свойству суммы углов треугольника. Использовать это свойство на практике возможно было и ранее, однако, только после появления StereoSurveys появилась возможность значительно сократить трудоемкость работ и увеличить точноность нанесения данных.

Для иллюстрации работы модуля, нанесем в точечном слое местоположение фонарных столбов на улице Текстильной (ХБК, город Шахты). Со спутникового снимка их не видно, поэтому единственный способ нанести их не от балды — воспользоваться описываемым методом.

0

Улица Текстильная, вдоль которой необходимо отметить фонарные столбы

1. Для начала скачиваем модуль с гит-хаба.  На тот случай, если гит-хаб закроют (твою-ж мать…) сохранил копию у себя на сервере. Последняя ссылка подойдет так-же для тех, у кого скачанный с гит-хаба архив не открывается (как у меня, например).

2. Скачанный архив необходимо распаковать в папку хранения модулей QGIS. Для windows XP это обычно C:\Documents and Settings\[username]\.qgis2\python\plugins для windows 7: C:\Users\[username]\.qgis2\python\plugins, для linux: /home/[username]/qgis2/python/plugins. Если в папке home отсутствует папка qgis2 (или .qgis2), то, возможно, у вас не отображаются скрытые файлы. В debian-подобных системах (debian, ubuntu, mint, OSGeoLive и др.) это исправляется так: правая кнопка мыши — отображать скрытые файлы.

3. Если у вас винда — обратите внимание на название папки [username]. Плагин не переносит кириллицу! Если в названии файла, проекта, плагина или пути к ним встретится русская буква, QGIS выдаст следующую ошибку:

Traceback (most recent call last):   File "", line 1, in   File "C:/PROGRA~1/QGISWI~1/apps/qgis/./python\pyplugin_installer\installer.py", line 274, in upgradeAllUpgradeable     self.installPlugin(key, quiet=True)   File "C:/PROGRA~1/QGISWI~1/apps/qgis/./python\pyplugin_installer\installer.py", line 322, in installPlugin     reloadPlugin(key) # unloadPlugin + loadPlugin + startPlugin   File "C:/PROGRA~1/QGISWI~1/apps/qgis/./python\qgis\utils.py", line 319, in reloadPlugin     loadPlugin(packageName)   File "C:/PROGRA~1/QGISWI~1/apps/qgis/./python\qgis\utils.py", line 200, in loadPlugin     msg = msgTemplate % (packageName, "', '".join(sys.path)) UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 9: ordinal not in range(128)

Для пользователей Windows 7, причина кроется как правило в том, что папка «Users» в этой системе названа как «Пользователи», кроме того, обычно кириллическое написание имеет папка  [username]. Теоретически, исправить эту беду можно создав новую учетную запись с правами администратора. Через нее следует войти завершив текущую сессию, после чего стандартным способом сменить название директорий на латиницу. Насколько это возможно и действенно, я утверждать не берусь — не проверял.

В Линуксе, как правило, папка [username] всегда может быть названа только латиницей. Поэтому, если у вас Линукс — переходите к следующему пункту.

4. Теперь можно запустить QGIS, либо перезапустить его, если он работал до этого.

В верхнем меню выбираем: модули — управление модулями-с ошибками. Ставим галку в чекбоксе stereo surveys и нажимаем установить

Снимок экрана от 2015-06-20 21_37_45

 

После установки появляется текст «Модуль неисправен invalid syntax». Презираем его и закрывая окно установки модулей.

Снимок экрана от 2015-06-20 21_37_59

 

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

Снимок экрана от 2015-06-20 21_40_00

На панорамах Google отображается площадь Прато-делла-Валле — что находится в Падуе, недалеко от Венеции. Это красивейшие места, но в качестве отправной точки для модуля не самые удачные — нам ведь требуется картировать шахтинскую улицу.

Для точечного слоя, создадим шейп-файл с названием test и системой координат EPSG: 3785 (можно и EPSG: 3857 — все работает, другие датумы не пробовал).

Снимок экрана от 2015-06-20 21_42_06

 

Что-бы вернуть его в рамки окна — перетащим таблицу слоев (менеджер слоев, TOC — все его по-разному называют) в нижнюю часть экрана.

Для того, что-бы картирование было более наглядным, подгрузим слой OpenStreetMap — Mapnik, воспользовавшись плагином OpenLayersPlugin.  Это не обязательно, но очень удобно. Приблизим нужный участок.

Рядом с левым верхним углом левой панорамы находится кнопка с зеленым индейцем. Нажимаем на эту кнопку, после чего выбираем на карте точку, из которой мы хотим видеть панораму. Обычно после этого в левом окне появляется панорама Google StreetView.

Рядом с правым верхним углом правой панорамы находится кнопка с красным индейцем. Нажимаем на эту кнопку, после кликаем на карте в то место, откуда мы хотим видеть вторую панораму. Обычно, это действие вызывает два последовательных сообщения об ошибке.

Первое сообщение об ошибке:

Снимок экрана от 2015-06-20 21_43_57

 

Второе сообщение об ошибке:

Снимок экрана от 2015-06-20 21_44_00

 

После нескольких неудачных попыток модуль срабатывает как надо и пользователь видит следующее:

— В окнах плагина видны панорамы из отмеченных точек и спутниковый снимок с тайлом, содержащий обе точки. Поверх панорам нанесены красные перекрестия как в прицеле.

— Непонятные числа, поля ввода и текст not calibrated слева и справа от окон с панорамами (первые два числа слева и справа — это координаты точки, в которой сделана панорама.

— Числа по центру, под окном со спутниковым снимком, которые обозначают следующее (я могу ошибаться):

H — высота точки, взятой на прицел в обоих панорамных окнах в метрах, относительно земли;

+/- — погрешность местоположения точки, взятой на прицел в обоих окнах, в метрах;

Lon, Lat — долгота и широта;

X,Y — неизвестные прямоугольные координаты;

— Под числами, расположена кнопка с текстом, «Digitize on map», по клику на которой, точка, взятая на прицел в обоих панорамах должна переносится в точечный слой.

— В окне отображения данных QGIS, помимо OSM-карты, пользователь видит три точки: зеленую — точка из которой снята панорама в левом окне StereoSurveys, красную — точка, из которой снята панорама в правом окне и желтую — точка, взятая на прицел в обоих окнах просмотра панорам.

Можно начинать работу. Находим на обоих панорамах одну и ту же точку. Кнопка Digitize on map не срабатывает, поэтому, включаем редактирование слоя и наносим ее вручную (кликаем по желтой точке, предварительно выбрав инструмент «добавить объект»). В проекте, который идет как пример к плагину, кнопка Digitize on map работает, но тоже далеко не всегда. Этот вопрос еще необходимо прояснить.

Находим один и тот же объект на двух снимках (в нашем случае это первый фонарный столб со знаком пешеходного перехода).

Снимок экрана от 2015-06-20 21_44_18

 

Прицеливаемся поточнее и стреляем — ставим точечный объект поверх желтой точки.

Снимок экрана от 2015-06-20 21_45_02

 

Точно так-же поступаем для остальных объектов. Картирование фонарного столба на противоположной стороне улицы.
Снимок экрана от 2015-06-20 21_47_33

 

Навигация осуществляется средствами Google StreetView. «Проезжаем» на несколько метров вперед в обоих окнах просмотра панорам и берем на прицел новый столб.

Снимок экрана от 2015-06-20 21_49_59

 

Иногда, без видимых причин возникает сообщение об ошибке:

Снимок экрана от 2015-06-20 21_51_10

 

Игнорируем его и продолжаем работать дальше.

Снимок экрана от 2015-06-20 21_53_17

 

Ради интереса, попытаемся изменить числа в полях StereoSurveys. Числа ввести можно только корректные. Насколько я понял из общения с Enrico, данные поля позволяют корректировать данные о высоте точки. Первое поле отвечает за высоту камеры над поверхностью земли (2.5 метра), второе за высоту поверхности земли (по умолчанию 0). Эти параметры особенно важны в горной местности с большими перепадами высот и при картировании объектов, находящихся на большом удалении от точек съемки панорам.

Не отвлекаемся и стреляем столбы дальше.

Снимок экрана от 2015-06-20 21_58_20

 

Процесс захватывает.

Снимок экрана от 2015-06-20 22_00_02 Снимок экрана от 2015-06-20 22_04_23 Снимок экрана от 2015-06-20 22_08_46 Снимок экрана от 2015-06-20 22_09_57

 

Первые несколько точек даются тяжело, но привыкание происходит очень быстро. Процесс прицеливания к снимкам улиц значительно проще указания общих точек (вертексов) при привязке растров.

Еще точечку.

Снимок экрана от 2015-06-20 22:13:22 Снимок экрана от 2015-06-20 22:23:21 Снимок экрана от 2015-06-20 22:25:19

 

В результате, мы получаем точечный слой, который планировали. После нанесения всех точек, закрываем модуль и сохраняем полученный слой. Иногда, после закрытия модуля красная и зеленая точки (точки съемки панорам) не исчезают, в этом случае, необходимо отключить модуль через меню-модули-управление модулями-снять галку с чекбокса напротив StereoSurveys и нажать «Закрыть».

Любопытный момент: обычно, снимки привязывают к gps-трекам. Я за всю Одессу говорить не буду, но в OpenStreetMap так и происходит. Думаю в Google тоже. При этом трек рассматривается в качестве центра дороги, что частично верно только для проселочных колейных дорог. Игнорирование понятия полосы дороги, приводит к системной ошибке в координатах до 5 метров (обычно +/- 3 м). Сама по себе, это величина небольшая, часто незначительная на фоне погрешности прибора. Однако, в том случае, если координаты объекта используются для расчетов детерминированных показателей, ошибки могут быть колоссальны. Это категорически запрещает использование популярных веб-проектов для расчета площади секторов, лежащих в створе с известными координатами, анализа видимости объектов, привязки объектов по двум точкам…, боюсь, этот список может оказаться длинным.

Обратите внимание на местоположение фонарного столба на улице Ворошилова.

Карта OpenStreetMap — столб стоит на дороге.

Снимок экрана от 2015-06-20 22:31:49

 

Карта Google. Аналогичное местоположение столба. Так-же, обратите внимание на местоположение дороги, относительно столбов освещения.

Снимок экрана от 2015-06-20 22:31:14

 

Загадка. В какую сторону ехал гугломобиль, если дело происходит в стране с правосторонним движением?

Снимок экрана от 2015-06-20 22:30:49

 

Впрочем, я немного отвлекся от темы. Как видно из описанного примера, модуль StereoSurveys, хотя и имеет много багов, но уже достаточно хорош для практического использования.

Вот карта фонарных столбов, полученная с помощью модуля:

Снимок экрана от 2015-06-20 22:27:30

 

А вот, та же карта, полученная два месяца назад вручную. Ошибки нанесения (дублирование столбов) — налицо.

9

 

В качестве завершения данного обзора, выкладываю список обнаруженных мною багов и неудобств, при использовании модуля StereoSurveys.

- Не работает с кириллицей;
- Не хватает угла обзора панорам как в модуле go2streetview;
- Возникает ошибка при попытке переместить точку на карте;
- Не работает кнопка Digitize on map;
- Плагин не реагирует, когда на обоих экранах одинаковый снимок (должно высвечиваться предупреждение);
- Не высвечивается предупреждение, если погрешность больше заданной величины;
- При запуске модуля должны отображаться снимки из текущих координат экстента;
- При наличии таблицы слоев, модуль выходит за размеры экрана;
- Не исчезают точки после закрытия плагина;
- Нет явного объяснения значения чисел и полей ввода в плагине;
- Много времени уходит на масштабирование снимков, не хватает кнопки "сбросить увеличение";
- Не хватает кнопки "назад" для каждого из окон панорам;
- Не хватает кнопки "вперед", перемещающей обе точки;

P.S. Спасибо Enrico Ferreguti за написание такого чудесного плагина. Десять лет назад я говорил, что скоро наступят времена, когда картографы долгими зимними вечерами будут превращать видеозаписи своих летних путешествий в точнейшие карты. Тогда надо мной все смеялись. Теперь, благодаря Enrico, я понимаю, что был прав.

Наземное фотограмметрическое картирование объектов с помощью Google StreetView, QGis и модуля go2streetview

Замечание 1. В данной статье не расматриваются юридические вопросы законности использования описанного метода при работе с данными компании Гугл. Мое дело метод показать, а с юристами сами разбирайтесь.
Замечание 2. Собственно, ничто не мешает использовать любые другие данные, вплоть до своих фотографий. Для этого необходимо только переписать модуль. К сожалению, моих познаний в языке для этого недостаточно. Была попытка написать отдельную программу для реализации этого метода (Borland С++ Builder 6) с произвольными фотографиями, но, ввиду отсутствия времени и денег работа была остановлена.

 

Данные проекта Google StreetView вполне успешно можно использовать не только для ориентирования на местности, но и для картографирования объектов. Причем речь идет не просто о нанесении на карту топонимики или примерного уточнения границ объектов. При небольших затратах возможно картирование объектов с точностью до нескольких метров. Особенно это актуально для объектов небольшого размера, которые невозможно отрисовать по спутниковому снимку (инфраструктура, растительность, ограждения, элементы зданий и др.).

Для иллюстрации метода, нанесем на карту столбы освещения на Текстильной улице города Шахты, Ростовской области. Сделать это по спутниковому снимку невозможно. Более того, по спутниковому снимку невозможно даже определить их наличие:

0

 

С помощью меню «Модули» -> «Управление модулями» установим модуль «go2streetview«. После чего откроем в QGis указанный район и запустим модуль. Сделать это можно перетаскиванием желтого человечка на необходимую точку улицы, точно так же как и в Google Maps. В новом окне откроется фотография улицы из указанной точки, а сама точка на карте будет обозначенна синим цветом с двумя лучами, иллюстрирующими рамки окна с фотографией.

1

 

Изменение угла обзора в окне go2streetview, автоматически изменяет положение лучей. Это замечательное свойство модуля, наряду со свойством треугольника, позволяет нам определить местоположение любого объекта, попадающего не менее чем на два снимка StreetView.

В окне панорамы приблизим первый столб и соориентируем вид таким образом, что-бы его пересекала рамка окна. После чего создадим вспомогательный линейный слой, в котором продлим продлим луч go2streetview. В моем случае, таким слоем является слой «водотоки» (по ленному недоразумению). К сожалению, модуль go2streetview не позволяет указать в настройках размеры лучей, поэтому приходится поступать таким методом.

2
Такую же процедуру повторим для столба на противоположной части дороги. Для удобства, можно использовать правую границу окна и правый луч соответственно.

Теперь откроем панораму с этими столбами снятую из другой точки. Сделать это можно кликнув по карте (не забудьте перед этим переключиться из режима редактирования слоя в режим модуля). Еще проще сделать это кликнув по стрелке в окне go2streetview.

В новом окне выполняем те же самые операции, что и ранее. Луч, проведенный из второй точки, в пересечении с первым лучом обозначит местоположение картируемого столба.

3
Находим противоположный столб.

4

 

Нанесем местоположение столбов на точечный слой. Сделать это можно в любой момент времени, но по мере работы вспомогательный слой постепенно загромождается лучами. В моем случае это затрудняет простановку точек после определения местоположения всех столбов.

5

 

В ходе работы необходимо следить за тем, что-бы не ошибиться в выборе рамки окна go2streetview. Когда постоянно «вертишься» в пространстве панорам, такая ошибка, особенно в начале работы, случается часто. Обычно, это сразу заметно по нехарактерному положению искомого объекта на плане.

Для нанесения точки можно использовать более двух лучей. Это повышает точность, но значительно увеличивает трудемкость. В нашем случае это не требуется.

6

 

Таким методом мы движемся вдоль всей улицы, редактируя точечный слой после каждого определения местоположения столба.

7

 

Получая в итоге следующее:

8

 

Теперь нам необходимо только отключить вспомогательный слой, подключить необходимые слои, добавить соль и перец по вкусу. Карта местоположения столбов освещения готова.

9