Агроном снимает поля дроном: сервер под снимки и историю по сезонам

MAATRIX

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

Карта памяти дрона — это буфер, а не архив

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

К середине сезона, когда вы уже сделали десяток облётов по нескольким полям, найти конкретную съёмку конкретного поля за конкретную дату становится нетривиальной задачей — если она вообще решаема. Имена файлов дрон присваивает по своей внутренней логике (номер кадра, дата в формате камеры), и без дополнительной сортировки через месяц уже не вспомнить, где тут третье поле от 12 июня, а где — то же поле, но с облёта в июле.

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

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

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

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

Если вы (или привлечённый специалист) в принципе используете обработку снимков — построение ортофотоплана поля или расчёт вегетационных индексов из мультиспектральной съёмки — исходники для этого тоже нужно где-то держать. Готовый индексный снимок без исходных кадров бесполезен, если через полгода понадобится пересчитать его другим методом или другим ПО: пересъёмка того же состояния поля уже невозможна, а исходники — единственное, из чего можно восстановить результат.

Структура архива: поле → сезон → облёт

Ключевая идея архива — жёсткая, предсказуемая структура папок, которая не зависит от того, как дрон или телефон назвали файлы по умолчанию. Раз выстроенная структура, которой вы придерживаетесь на каждом облёте, экономит часы поиска позже. Рабочий вариант для сервера:

/data/fields/
├── field-07-severnoe/
│   ├── 2024/
│   │   ├── 2024-05-14_vskhody/
│   │   │   ├── raw/              # исходные снимки с дрона как есть
│   │   │   ├── orthophoto/       # склеенный ортофотоплан, если строите
│   │   │   └── notes.txt         # фаза культуры, погода, что заметили
│   │   ├── 2024-06-20_kushchenie/
│   │   └── 2024-08-02_pered-uborkoj/
│   └── 2025/
│       ├── 2025-05-16_vskhody/
│       └── ...
├── field-08-yuzhnoe/
│   └── ...

Имя поля стоит фиксировать один раз и не менять — не «поле у дороги», а условный код (field-07) плюс человекочитаемое название, чтобы через три года не путаться, какое поле имелось в виду. Дата облёта в имени папки в формате ГГГГ-ММ-ДД сортируется естественным образом в любом файловом менеджере, а короткая пометка вроде «всходы» или «перед уборкой» сразу подсказывает фазу культуры без необходимости открывать файлы.

Текстовый файл notes.txt рядом со снимками — не формальность: через год вы не вспомните, что в этот день был ветер и часть кадров смазана, или что накануне прошёл дождь и часть поля выглядит темнее обычного не из-за проблем с посевами, а из-за влажной почвы. Такие заметки на месте съёмки занимают минуту, а при сравнении сезонов избавляют от ложных выводов.

Если ведёте съёмку по нескольким культурам или полям под разными севооборотами, культуру и сорт тоже стоит фиксировать в заметке к каждому облёту — сравнение «поле в этом году под подсолнечником» с «полем в прошлом году под пшеницей» по вегетационным индексам мало о чём говорит без этого контекста.

Сколько места закладывать и какой диск брать

Точный вес одного облёта зависит от разрешения камеры дрона, площади поля, режима съёмки (одиночные кадры или серия для склейки в ортофотоплан) и от того, снимаете ли вы в RAW или сразу в сжатом формате — единой цифры, подходящей всем, не существует, и любые конкретные гигабайты на облёт стоит мерить на своём оборудовании, а не брать из чужой статьи. Ориентируйтесь на практическую логику: возьмите вес одного своего типового облёта (посмотрите в свойствах папки после переноса пары съёмок), умножьте на количество полей и на ожидаемое число облётов за сезон — и заложите к получившейся цифре запас, а не берите тариф впритык.

Пара практических соображений при выборе диска под архив:

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

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

Отдельный вопрос — резервная копия архива. Сервер с одним диском защищает от потери карты памяти дрона, но не защищает от отказа самого диска сервера. Если снимки за несколько сезонов — это данные, которые физически невозможно пересъёмать задним числом, имеет смысл держать вторую копию архива отдельно от основного хранилища, а не полагаться на единственный диск как на окончательное решение.

Перенос снимков с дрона на сервер

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

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

#!/bin/bash
# usage: ./import-flight.sh field-07-severnoe vskhody /path/to/sd-card
FIELD=$1
PHASE=$2
SRC=$3
DATE=$(date +%Y-%m-%d)
DEST="/data/fields/${FIELD}/$(date +%Y)/${DATE}_${PHASE}/raw"

mkdir -p "$DEST"
rsync -avP --progress "$SRC"/*.{jpg,JPG,dng,DNG} "$DEST"/
echo "Облёт ${FIELD} (${PHASE}) от ${DATE} перенесён: $(ls "$DEST" | wc -l) файлов"

rsync предпочтительнее простого копирования тем, что докачивает файлы при обрыве связи и не начинает перенос заново с нуля — актуально, если синхронизация идёт через нестабильный мобильный интернет с поля. Если у вас несколько человек, которые могут делать облёты (сами, наёмный оператор дрона, консультант), тот же скрипт с параметрами избавляет от разнобоя в именовании папок между разными людьми — куда надёжнее, чем полагаться на то, что каждый запомнит формат вручную.

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

Доступ для консультанта и совместная работа с архивом

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

Практичный вариант — Nextcloud: разворачивается на том же сервере, что и архив, даёт веб-интерфейс с просмотром фотографий прямо в браузере (без скачивания всей папки), и позволяет выдать консультанту доступ ровно к нужным полям и сезонам, не открывая весь архив целиком. Подробный разбор установки — в статье как установить и настроить Nextcloud на VPS.

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

Похожая по духу задача — не только у агрономов: геодезисты сталкиваются с тем же принципом «данные снятые один раз, задним числом не пересъёмать», работая с облаками точек — как они организуют архив, можно посмотреть в статье про хранение облаков точек геодезиста на сервере. А если объём фотоматериала в вашей практике вообще большой — держать его без облачных сервисов сторонних платформ и полностью под своим контролем — разбор похожей ситуации на примере фотографа есть в статье фотограф отдал клиенту 4 ТБ съёмок без облака.

Частые вопросы