Earth Engine — это облачная платформа для геопространственного анализа данных в планетарных масштабах. Она позволяет использовать огромные вычислительные мощности компании Google для изучения самых разнообразных проблем: потерь лесов, засухи, стихийных бедствий, эпидемий, продовольственной безопасности, управления водными ресурсами, изменения климата и защиты окружающей среды. Чтобы избежать путаницы в названиях, сразу определим, что Google Earth (он же — Google Планета Земля) и Google Earth Engine — это два разных продукта. Первый, не требуя от пользователей особых компьютерных навыков, предназначен для визуализации спутниковых снимков и позволяет путешествовать и исследовать мир, взаимодействуя с виртуальным глобусом. Второй, которому посвящена эта статья, — это прежде всего инструмент для анализа данных. Использование Earth Engine предполагает знание прикладной области и умение писать программный код. Ссылка на официальный сайт проекта.

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

По личному опыту можем сказать, что даже в англоязычной профессиональной среде про Earth Engine знают пока немногие, а в России и СНГ платформу используют единицы. По этой теме во всём рунете есть только короткая заметка 2012 года на Хабре. Для исправления ситуации мы решили начать серию публикаций, посвящённых Earth Engine. Начнём с обзора того, чем является эта платформа, какие значимые проекты на ней уже сделаны, и что можно почитать по этой теме.

Оглавление

1. Немного истории
2. Технический обзор платформы
   2.1. Каталог данных
   2.2. Архитектура системы
   2.3. Модели данных
   2.4. Функции
   2.5. Модели распределения данных
   2.6. Производительность и масштабируемость
   2.7. Существующие проблемы и перспективы развития
3. Расширение возможностей платформы
   3.1. Конструктор приложений Earth Engine Apps
   3.2. Расширение для QGIS
4. Примеры проектов на Earth Engine
5. Справка и обучение
6. Поддержка
   6.1. Сообщество пользователей
   6.2. Связь с разработчиками
7. Альтернативы Earth Engine
8. Итог

1. Немного истории

В 2009 году на Международной конференции ООН по изменению климата в Копенгагене компанией Google был представлен новый технологический прототип, который позволял осуществлять глобальный онлайн-мониторинг изменений лесного покрова Земли. Тогда образец был доступен для тестирования лишь небольшому числу партнёров компании.

В 2010 году на следующей конференции ООН по изменению климата в Канкуне, в рамках Лаборатории Google, инкубатора идей для новых сервисов, был запущен проект Earth Engine. В то время, набор имеющихся в нём данных ограничивался коллекцией снимков программы дистанционного зондирования Земли Landsat, но уже этого было достаточно для получения впечатляющих результатов по глобальной оценке изменений лесов и проявления интереса к разработке Google.

Широкая общественность обратила внимание на Earth Engine в 2013 году, когда в СМИ начали появляться публикации с анимациями многолетних изменений земной поверхности. Уничтожение лесов Амазонки, таяние ледников Аляски, разрастание мегаполисов и многое другое поразило публику своей красотой и драматизмом.

В 2016 году запускается проект Google Earth Timelapse — это такая галерея самых зрелищных изменений, произошедших на поверхности Земли, которая активно освещалась в СМИ, что также не могло не привлечь внимание публики. Именно с этого момента авторы данной статьи и узнали о существовании платформы Earth Engine. По графику ниже видно, что стабильный рост поисковых запросов «Google Earth Engine» начинается именно с 2016 года.

Динамика популярности поискового запроса «Google Earth Engine» c 1 января 2009 года по 16 апреля 2020 года. Пик в 2010 году соответствует Международной конференции ООН по изменению климата, когда платформа Earth Engine была впервые представлена; в 2013 — масштабным публикациям в СМИ; в 2016 — запуску портала Google Earth Timeseries. После этого популярность платформы только растёт. Источник: Google Trends

И хотя интерес широкой аудитории к Earth Engine в свете проблем окружающей среды — вещь довольно непостоянная, научное сообщество быстро взяло эту платформу на вооружение. Так, количество публикаций в рецензируемых журналах, а также в материалах различных конференций, стало неуклонно расти. В 2017 году в авторитетном журнале Remote Sensing of Environment была опубликована статья от разработчиков платформы — Google Earth Engine: Planetary-scale geospatial analysis for everyone, которая на сегодняшний день даёт наиболее целостное и подробное описание работы этой системы.

Динамика количества публикаций, связанных с Google Earth Engine, рассчитанная по информации из наукометрической реферативной базы данных Scopus, охватывающей научно-исследовательскую литературу со всего мира.

К концу 2019 года каталог Earth Engine объёмом 29 петабайт содержал более 600 различных наборов данных, а скорость пополнения информации достигла одного петабайта в месяц. В том же году в Калифорнии прошла конференция Geo for Good Summit 2019, объединившая пользователей Google Earth Engine и участников Google Earth Outreach, инициативы по продвижению идей защиты окружающей среды. Это было масштабное мероприятие, на котором учёные, некоммерческие организации и другие участники собрались для обсуждения проектов по положительному влиянию на нашу планету и её жителей. Посмотрите на выступление Ребекки Мур и Мэтта Ханчера из Google, где они разбирают серию проектов Google Earth и отдельно рассказывают про Earth Engine.

Таким образом, с момента запуска Earth Engine прошло уже 10 лет, и мы можем смело сказать, что платформа стала зрелым продуктом. И, что не менее важно, вокруг неё выросло активное сообщество пользователей.

2. Технический обзор платформы

Этот раздел содержит выдержки из статьи N. Gorelick, M. Hancher, M. Dixon, S. Ilyushchenko, D. Thau, and R. Moore, “Google Earth Engine: Planetary-scale geospatial analysis for everyone,” Remote Sensing of Environment, vol. 202, pp. 18–27, 2017 с нашими дополнениями и изменениями.

Как мы уже упомянули, Earth Engine — это многопетабайтный каталог данных, интегрированный с высокопроизводительным кластером серверов для параллельных вычислений. Доступ к системе и управление осуществляется через интерфейс прикладного программирования (API). Пользователь создаёт сценарии обработки данных в интерактивной среде разработки на JavaScript API, которая называтеся редактором кода (Code Editor) и обеспечивает оперативное создание прототипов и визуализацию результатов «на лету». То же самое можно выполнять и через Python API в локальной среде на своём компьютере или через облачные блокноты Google Colab. В каждом из вариантов основные вычисления выполняются на серверах Google.

Каталог Earth Engine содержит множество общедоступных наборов геопространственных данных:

• Космо- и аэрофотоснимки, сделанные в различных диапазонах электромагнитного спектра
• Модели прозноза погоды и параметры климата
• Карты земного покрова
• Топографические и социально-экономические наборы данных
• Различные параметры окружающей среды (например, влажность почвы или исходящее тепловое излучение Земли)

Все эти данные предварительно приводятся во внутренний формат системы. Он сохраняет тип исходных данных и метаданные, обеспечивая при этом эффективный доступ к информации, и устраняет технические барьеры, связанных с параллельной обработкой больших объёмов данных. Пользователи могут заправшивать и анализировать данные из общедоступного каталога, или же загружать свои собственные. Доступ к Earth Engine API осуществляется либо через библиотеку Python, либо через веб-IDE, построенный поверх клиентской библиотеки на JavaScript.

Редактор кода Earth Engine — это интерактивная веб-среда разработки на JavaScript.

Блокнот Google Colab в котором происходит интерактивный анализ данных через Python API.

По нашему опыту, для начинающих пользователей лучше подходит использование API на JavaScript, так как он хорошо документирован, для него доступно много обучающих материалов, а главное — не требуется предварительной настройки среды. Авторизация и настройка среды для визуализации происходят автоматически при запуске редактора кода в браузере. Применение Python API требует от пользователя хорошего знания архитектуры Earth Engine и понимания клиент-серверной модели программирования с её особенностями. Так, нельзя смешивать вызовы библиотеки Earth Engine с некоторыми языковыми конструкциями локальной среды. Также при использовании Python API для отрисовки результатов потребуется настроить среду визуализации, например, с помощью библиотеки Folium. Так что в целом мы советуем начать освоение платформы с JavaScript API, а затем, когда вы почувствуете себя «продвинутым» пользователем, переходить к Python API, который может предоставить более гибкие возможности по обработке данных из каталога Earth Engine.

Для использования Earth Engine необходимо иметь аккаунт Google, после чего пользователь может запросить доступ к платформе на странице создания учётной записи Earth Engine. Прежде чем приступить к работе, необходимо подождать, пока ваш аккаунт будет одобрен. Обычно письмо с подтверждением приходит в течение нескольких часов или даже минут, однако процесс одобрения заявки может занять и большее время.

Предшествующий опыт в ГИС, дистанционном зондировании и разработке скриптов облегчает начало работы, но эти знания не являются строго обязательными, а руководство пользователя Earth Engine ориентировано на начинающих пользователей. Также на официальном сайте проекта размещены учебные пособия, примеры, обучающие видео, справочники функций и учебные программы, ссылки на которые даны в конце статьи в разделе «Справка и обучение».

Ещё раз подчеркнём, что помимо общего каталога геоданных, Earth Engine позволяет загружать и использовать собственные наборы данных. Результаты работы могут быть выгружены для автономного использования, например, в Google Drive.

2.1. Каталог данных

Общедоступный каталог данных Earth Engine (Earth Engine Data Catalog) представляет собой огромный архив часто используемых наборов геопространственных данных. Большая часть каталога состоит из изображений дистанционного зондирования Земли, включая весь архив миссии Landsat (а это почти полвека наблюдений), а также полные архивы данных от европейских спутников Sentinel-1, Sentinel-2, Sentinel-3, Sentinel-5P с различными уровнями обработки, климатические прогнозы, данные о земном покрове, геофизические, экологические и социально-экономические наборы данных. В каталоге есть удобный инструмент поиска, включая поиск по тегам.

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

Общедоступный каталог данных Earth Engine.

2.2. Архитектура системы

Earth Engine построен на основе набора технологий, доступных в среде дата-центров Google:

• Система управления кластерами Borg
• Распределённые базы данных Cloud Bigtable и Cloud Spanner
• Файловая система Colossus, преемник Google File System
• Инфраструктура FlumeJava для параллельной работы конвейеров данных

Earth Engine также взаимодействовал с Google Fusion Tables, работа которого была остановлена в 2019 году.

На рисунке ниже представлена упрощенная архитектура системы. Редактор кода Earth Engine (Code Editor) и сторонние приложения используют клиентские библиотеки для отправки интерактивных или пакетных запросов в систему через REST API. Запросы «на лету» обрабатываются серверами переднего плана (фронтенды), которые направляют сложные подзапросы на главные узлы, распределяющие вычисления среди пула рабочих вычислительных узлов. Система пакетных вычислений работает аналогичным образом, но использует FlumeJava для управления распределёнными вычислениями. Поддержкой обеих вычислительных систем занимаются службы данных, включающие, например, базы фондов данных, которые содержат метаданные для каждого изображения и обеспечивают эффективную фильтрацию данных. Программное обеспечение Borg для управления всем кластером контролирует каждый компонент системы, и каждый сервис распределён по нагрузке между несколькими вычислительными серверами. Отказ любого отдельного рабочего узла просто приводит к тому, что вызывающая сторона переиздает запрос.

Упрощённая архитектура Earth Engine. Оригинал схемы опубликован в N. Gorelick et al. / Remote Sensing of Environment 202 (2017) 18–27; мы удалили упоминание закрытого в 2019 г. сервиса Fusion Tables из блока хранилищ данных.

Пользователи создают запросы к Earth Engine, используя функции, взятые из библиотеки API. На момент написания этой статьи (апрель 2020 года), это более чем 1500 функций, которые варьируются по сложности от простых математических операций до машинного обучения, мощных геостатистических инструментов и операций обработки изображений. Библиотека позволяет легко осуществлять операции между изображениями с использованием растровой алгебры и поддержкой функций более высокого порядка: map() и iterate(), которые позволяют применять произвольные функции к коллекциям изображений. Для вычисления статистики по коллекциям изображений применяется оператор свёртки reduce(), который, к примеру, может аггрегировать данные методом скользящего окна. Полный список всех функций доступен в справочном руководстве Earth Engine API Reference.

2.3. Модели данных

Earth Engine использует простую и максимально общую модель данных, основанную на двумерных растровых каналах, собранных в контейнеры «изображений» (Image). Пиксели в каждом канале должны быть однородными по типу данных, разрешению и проекции. Однако каналы в одном изображении-контейнере могут иметь разные типы данных или даже проекции, а сами изображения могут содержать любое количество каналов. Каждое изображение также может иметь связанные метаданные вида «ключ/значение», содержащие такую информацию, ​​как местоположение, время создания данных и условия, при которых изображение было получено или обработано. Изображения, объединённые по смыслу, например, изображения от одной съёмочной аппаратуры спутника, группируются и представляются в виде «коллекции изображений» (ImageCollection). Коллекции предоставляют функционал для быстрой фильтрации и сортировки по определённым пространственным, временным или другим критериям, которые облегчают пользователям выбор данных среди миллионов отдельных изображений. Например, с помощью методов фильтрации коллекций пользователь может легко выбрать мультиспектральные снимки со спутника Landsat-8, покрывающие территорию Московской области и полученные в период с июня по август за 2019 и 2020 годы, с облачным покровом менее 10%.

Изображения, загруженные в Earth Engine, предварительно обрабатываются для обеспечения быстрого и эффективного доступа. Сначала они нарезаются на тайлы в исходной проекции и разрешении и сохраняются в производительной и реплицированной тайловой базе данных. Стандартный размер тайла в 256×256 пикселей был выбран в качестве практического компромисса между загрузкой ненужных данных и затратами на дополнительные операции чтения. В отличие от традиционных систем типа «куб данных» (data cube), этот процесс ввода данных сохраняет информацию: изображения всегда хранятся при исходной проекции, пространственном и радиометрическом разрешении. Это позволяет избежать ухудшения качества данных, которое было бы присуще при ресемплинге всех изображений к фиксированной сетке, которая может быть, а может и не быть подходящей для каждого конкретного применения.

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

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

2.4. Функции

Основную часть функций библиотеки, созданных для обработки изображений, составляют алгебраические попиксельные операции, которые оперируют пикселами внутри каналов (per-band basis) или соответствующими пикселами разных каналов (band-to-band basis), охватывая целочисленные математические вычисления и вычисления с плавающей точкой, логические сравнения, манипулирование битами, преобразования типов данных, замену значений по условию и операции над многомерными массивами. Также включены общие функции управления пикселями, такие как поиск в таблице (table lookup), кусочно-линейная интерполяция, полиномиальная оценка и вездесущая нормализованная разность. Библиотека использует несколько уже существующих инструментальных средств машинного обучения, чтобы обеспечить лёгкий доступ к более чем 20 типам контролируемой классификации, регрессии и неконтролируемой классификации (кластеризации), а также операциям с матрицами несоответствий для оценок точностей. Для задач машинного зрения доступны обычные оконные операции на основе ядра (kernel), такие как свёртка, морфологические операции, анализ расстояний и текстур, а также простые операции на основе соседства, такие как градиент, наклон, аспект и связность. Другие возможности включают в себя операции с метаданными изображения и каналами, манипуляции с проекцией и ресемплингом, маскирование и обрезку, смещение и корегистрацию изображения по отношению к другому, а также множество специализированных инструментов, общих для сферы дистанционного зондирования, включая операции спектрального разложения (spectral unmixing), наращивание пикселей (region growing) и картирования стоимости (cost mapping).

Безоблачная мультиспектральная мозаика территории Панамы, полученная в Earth Engine в результате обработки 1239 спутниковых снимков Landsat-8. Для её создания для каждого пиксела был применён набор операций с целью отсеять облачные данные и извлечь медианное значение данного пиксела в стеке снимков. Центр ДЗЗ РУДН, 23 апреля 2019 г.

Любые функции из библиотеки могут быть использованы в алгоритмах, которые пользователь желает выполнить. Описание алгоритма конвертируется в ориентированный ациклический граф (ОАГ), в котором каждая вершина представляет выполнение отдельной функции или метода доступа к данным и содержит пары ключ/значение именованных аргументов функции. По сути, это чисто функциональная среда программирования, и Earth Engine использует стандартные методы, обычно применяемые в функциональных языках, такие как ссылочная прозрачность и ленивые вычисления, для существенной оптимизации и повышения эффективности.

Пользователи пишут программы для Earth Engine, используя для этого клиентские библиотеки, доступные для языков Python и JavaScript, которые позволяют описывать обработку графов с применением знакомой многим парадигмы процедурного программирования. Клиентские библиотеки предоставляют собой прокси-объекты для изображений (ee.Image), коллекций (ee.ImageCollection) и других типов данных, таких как числа (ee.Number), строки (ee.String), геометрии или векторные объекты (ee.Geometry) и списки (ee.List). Пользовательские сценарии управляют этими прокси-объектами и записывают цепочку операций, собирая их в ОАГ, который и выражает полное вычисление.

Через последовательность графовых преобразований эти ОАГ затем отправляются в вычислительный кластер Earth Engine. Подграфы «жадно» упрощаются за счёт немедленных расчётов, где это возможно, чтобы избежать избыточных вычислений. Например, подграф, представляющий 3+7, будет немедленно упрощён до значения 10. Другие вершины в графе раскладываются на несколько: например, когда оценивается точка графа, которая ссылается на коллекцию изображений, то она расширяется до последовательности изображений, которые будут использоваться партиями при последующих операциях обработки. Вершины, которые представляют сложные операции обработки, могут использовать любую из нескольких стратегий распределённой обработки, описанных далее в разделе «Модели распределения данных».

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

Упрощённый образец этого можно показать, используя клиентскую библиотеку Earth Engine для вычитания двух композитных изображений. Для этого в веб-редакторе кода надо запустить следующий сценарий на языке JavaScript:

// Вычисление разницы медианных композитов между двумя сезонами
collection = ee.ImageCollection("LANDSAT8")
winter = collection.filter(ee.Filter.calendarRange(11, 1, "month"))
summer = collection.filter(ee.Filter.calendarRange(6, 8, "month"))
diff = summer.median().subtract(winter.median())

Этот код создает две отфильтрованные коллекции:

1. winter: все изображения Landsat-8, снятые в ноябре, декабре и январе за все годы
2. summer: все изображения Landsat-8, снятые в июне, июле и августе за все годы

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

Ориентированный ациклический граф, представляющий вычисление для кода выше. N. Gorelick et al. / Remote Sensing of Environment 202 (2017) 18–27.

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

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

Подход к вычислениям в Earth Engine поощряет интерактивный и итеративный режим исследования данных и разработки алгоритмов. Как только пользователь разработал алгоритм, который он хотел бы масштабировать на бóльшую территорию, он может отправить запрос на пакетную обработку (batch-processing request) в Earth Engine, чтобы вычислить полный результат и материализовать его либо как изображение в окне карты редактора кода, либо сохранить на свой компьютер в виде геопривязанного Tiff-файла, таблицы, графика или видеофайла с анимацией. Сохранение обычно осуществляется через экспорт результатов в личный Google Drive пользователя.

2.5. Модели распределения данных

Функции в библиотеке Earth Engine используют несколько встроенных моделей распараллеливания и распределения данных для достижения высокой производительности. Каждая из этих моделей оптимизирована для разных схем доступа к данным.

2.5.1. Тайлы изображений

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

Пирамиды представляют собой серию изображений с пониженным пространственным разрешением. Каждый последующий слой пирамиды подвергается ресемплингу (понижающей дискретизации) в масштабе 2:1.

Большинство операций на основе тайлов реализованы в Earth Engine с использованием одной из двух стратегий, в зависимости от их вычислительной стоимости. Затратные операции и операции, которые значительно выигрывают от одновременного вычисления всего тайла сразу, записывают результаты в выходной буфер размером с тайл. Размер этих тайлов обычно составляет 256×256 пикселей, чтобы соответствовать размеру тайлов предварительно обработанных входных данных.

Незатратные попиксельные операции осуществляются с использованием интерфейса pixel-at-time (пиксель-за-раз), в котором операции обработки изображения непосредственно вызывают друг друга в графе. Эта схема предназначена для использования преимуществ того, что эти операции выполняются в среде виртуальной машины Java с динамическим JIT-компилятором, который извлекает и компилирует последовательности повторяющихся вызовов функций. В результате во многих случаях произвольные цепочки примитивных операций с изображениями, таких как растровой алгебры, могут выполняться почти так же эффективно, как и скомпилированный вручную код.

2.5.2. Пространственная агрегация

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

В Earth Engine эти типы вычислений выполняются как распределённые процессы, использующие модель Scatter/Gather (разброс/сбор). Пространственная область, в которой должна выполняться агрегация, делится на подрегионы, которые назначаются рабочим узлам в распределённом кластере. Каждый рабочий узел получает или вычисляет входные пиксели, в которых он нуждается, а затем выполняет требуемую операцию накопления, чтобы рассчитать промежуточные результаты. Эти результаты отправляются обратно в главный узел, который объединяет их и преобразует в окончательный результат. Например, при вычислении среднего значения каждый рабочий узел будет вычислять суммы и количество значений, а главный узел собирает и суммирует эти промежуточные результаты, и конечным результатом будет общая сумма, делённая на общее количество.

Эта модель очень похожа на традиционную MapReduce, однако пользователь не обязан знать об этой реализации и должен только указать проекцию карты, разрешение и пространственную область, в которой будет выполняться операция, которая, в свою очередь, определяет количество подрегионов и сетку, где будут вычисляться входные пиксели. Чаще всего каждый подрегион кратен размеру входного тайла по умолчанию (обычно 1024×1024 пикселей), чтобы минимизировать издержки удалённого вызова процедур во время этих вычислений. Однако из-за большого диапазона вычислительных сложностей промежуточных продуктов, которые пользователи могут пытаться агрегировать, в систему были введены элементы управления, позволяющие пользователям корректировать это кратное число, если этого требуют их вычисления, например, из-за ограничений памяти на один рабочий узел.

2.5.3. Потоковые коллекции

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

Эта модель распределения может быть быстрой и эффективной для агрегаторов, которые имеют небольшое промежуточное состояние (например, вычисление минимального значения), но для иных агрегаторов она может быть чрезмерно интенсивной. К примеру, корреляция Пирсона требует сохранения полного ряда данных в каждом пикселе до вычисления окончательного результата. Потоковая передача даже по очень большим коллекциям может быть быстрой, если размер тайла значительно меньше, чем размер полного изображения. Например, весь набор коллекций Landsat-5, -7 и -8, в совокупности содержащий более 5 миллионов изображений, имеет глубину менее 2000 тайлов в любой точке, а в среднем только около 500.

2.5.4. Кэширование и устранение общих подвыражений

Многие операции обработки в Earth Engine могут быть затратными и интенсивными в плане использования данных, поэтому полезно избегать избыточных вычислений. Например, результаты запросов пользователя к карте (перемещение или зумирование) будут вызывать несколько независимых запросов на выходные тайлы, все из которых часто зависят от одного или нескольких общих подвыражений, таких как большая пространственная агрегация или обучение контролируемого классификатора. Чтобы избежать пересчёта значений, которые уже были запрошены ранее, затратные промежуточные результаты сохраняются в распределённом кэше, используя хэш подграфа в качестве ключа кэша.

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

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

2.6. Производительность и масштабируемость

Earth Engine использует преимущества JIT-компилятора Java для оптимизации выполнения цепочек попиксельных операций, которые довольно распространены при обработке изображений. Чтобы оценить прирост эффективности, обеспечиваемый JIT-компилятором, был проведен ряд экспериментов для сравнения производительности трёх моделей выполнения:

1. Выполнение графа вычислений в Java с использованием JIT-компилятора
2. Выполнение графа с использованием аналогичной общей реализации на C++
3. Выполнение тех же самых вызовов напрямую, а не через граф, в специализированном нативном коде C++, что позволило избежать виртуализации функций

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

1. SingleNode: тривиальный граф с одной вершиной, состоящей из пространственного буфера данных изображения. Этот тест просто вычисляет сумму всех значений в буфере.
2. NormalizedDifference: граф, который вычисляет нормализованную разницу двух входных буферов. Этот сценарий с небольшим графом содержит в общей сложности пять вершин: две входных вершины, одну сумму, одно произведение и одно частное.
3. DeepProduct: граф, состоящий из цепочки 64 вершин произведений, вычисляющий его для 65 входных вершин.
4. DeepCosineSum: граф с той же структурой, что и DeepProduct, где каждая вершина вычисляет более затратную бинарную операцию cos(a+b).
5. SumOfProducts: граф, который вычисляет сумму для всех парных произведений из наборов входных данных. Он имеет 40 входных вершин, 780 вершин произведений и 779 вершин суммирования. Здесь общее количество точек намного больше, чем количество входных вершин, что позволяет оценивать производительность сложных графов, состоящих из примитивных операций на фиксированном количестве входных данных — распространённый в реальном мире сценарий.

Каждый из этих тестов проводился на одном тайле размером 256×256 пикселей, используя конфигурацию, типичную для облачной среды коммерческого дата-центра: однопоточную среду выполнения на процессоре Intel Sandy Bridge с тактовой частотой 2,6 ГГц с отключением всех несущественных системных служб для минимизации шума при профилировании. Результаты, приведенные ниже, показывают, что в 4 из 5 распространённых сценариев Java с JIT-компилятором превосходит аналогичные вычисления на основе динамических графов на C++ примерно на 50%, а в одном случае даже превосходит прямую реализацию на C++.

Результаты тестов эффективности Java JIT против C++. N. Gorelick et al. / Remote Sensing ofEnvironment 202 (2017) 18–27.

2.6.1. Производительность системы

В дата-центре Google нет недостатка в процессорах. В этой среде продуктивность их использования хоть и важна, но не так критична, как способность эффективно распределять сложные вычисления по множеству машин. Большая часть производительности Earth Engine обусловлена ​​его способностью распределять вычисления и управлять большим количеством CPU от имени пользователя. Существует жёсткий верхний предел эффективности, который может быть достигнут с помощью оптимизации кода или запросов, но есть гораздо меньше ограничений на дополнительные вычислительные ресурсы, которые могут быть задействованы.

С целью демонстрации способности Earth Engine горизонтально масштабироваться была проведена серия экспериментов. В рамках тестов две большие коллекции изображений Landsat были перепроецированы в общую картографическую проекцию, агрегированы для каждого пикселя по времени и в пространстве до одного числа при варьировании количества процессоров в тесте. Две коллекции состояли из всех доступных снимков Landsat-8 уровня обработки 1T, полученных с 1 января 2014 по 31 декабря 2016 года, и покрывающих две территории:

• Смежная территория США (Contiguous United States): 26 961 сцена и 1,21 триллиона пикселей
• Африка: 77 528 сцен и 3,14 триллиона пикселей.

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

Результаты горизонтального масштабирования. N. Gorelick et al. / Remote Sensing of Environment 202 (2017) 18–27.

2.7. Существующие проблемы и перспективы развития

Одним из преимуществ использования Earth Engine является то, что пользователь почти
полностью отстранён от деталей среды параллельных вычислений. Система обрабатывает и скрывает почти все аспекты управления вычислениями, включая распределение ресурсов, параллелизм, распределение данных и повторные попытки. Эти решения носят исключительно административный характер, и ни одно из них не может повлиять на результат запроса, а только на скорость, с которой он создается. Цена опущения этих деталей заключается в том, что пользователь не может повлиять на них: система несёт полную ответственность за принятие решений о том, как выполнять вычисления. Это приводит к некоторым интересным проблемам как при проектировании, так и при использовании системы.

2.7.1. Трудности масштабирования

Система Earth Engine в целом может управлять чрезвычайно большими вычислениями, но базовая инфраструктура в конечном итоге представляет собой кластеры рабочих серверов нижнего уровня. В этой среде опция конфигурирования произвольно больших машин недоступна, и существует жёсткое ограничение на объём данных, которые можно перенести на любой отдельный сервер. Это означает, что пользователи могут осуществлять большие вычисления только с помощью примитивов параллельной обработки, предоставляемых в библиотеке Earth Engine, и некоторые непараллелизируемые операции просто не могут быть эффективно выполнены в этой среде. Кроме того, необходимость выполнять вычисления с использованием библиотеки Earth Engine означает, что существующие алгоритмы и рабочие процессы пользователя должны быть преобразованы для использования API Earth Engine, чтобы так или иначе задействовать платформу.

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

Поскольку Earth Engine является общедоступным вычислительным ресурсом, то для того, чтобы пользователи не злоупотребляли платформой, требуются ограничения и другие средства защиты. Для интерактивных сеансов Earth Engine накладывает определённые лимиты. На момент 2017 года они были следующие:

• Максимальная продолжительность запроса: 270 с
• Общее количество одновременных запросов на пользователя: 40
• Количество одновременных выполнений некоторых дорогостоящих операций, таких как пространственные агрегации: 25

Когда запросы вызываются в пакетном режиме, ни одно из интерактивных ограничений не применяется. Однако всё еще применяется ограничение ресурсов каждого рабочего узла, когда запрос включает вычисления на основе тайлов, которые не могут быть переданы потоком или далее распределены с использованием текущей модели данных. Это ограничение памяти не переводится непосредственно в конкретное пространственное или временное ограничение, но общее правило таково: глубина стека в запросе не должна превышать 2000 байтов на пиксель. Текущая система удалённого вызова и кэширования налагает дополнительное ограничение, которое применяется как в интерактивном, так и в пакетном случаях: размер отдельных кэшируемых объектов не может превышать 100 МБ. Этот предел чаще всего достигается, тогда когда вывод операции агрегирования очень велик. Например, при извлечении данных для алгоритма машинного обучения, где он может ограничивать общее количество точек в обучающей выборке (training set).

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

2.7.2. Ограничения вычислительной модели

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

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

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

2.7.3. Особенности клиент-серверного программирования

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

Стоит отметить, что подобный стиль программирования становится всё более распространенным явлением для крупномасштабных облачных вычислений; он также используется в TensorFlow при построении и выполнении графов.

2.7.4. Будущее платформы

Главная цель Earth Engine — добиться прогресса в решении важнейших задач общества, сделав задачи мониторинга, отслеживания и управления окружающей средой и ресурсами Земли не просто осуществимыми, но и простыми. Для этого необходимо не только обеспечить доступ к огромному количеству данных и вычислительным мощностям, но также упрощать использование всё более изощрённых методов анализа данных. Именно для этого разработчики платформы продолжают эксперименты по интеграции методов глубокого обучения и упрощению доступа к другим масштабируемым инфраструктурам, таким как Google Compute Engine и BigQuery.

3. Расширение возможностей платформы

3.1. Конструктор приложений Earth Engine Apps

В 2018 году Google запустил новый API Earth Engine Apps для проектирования интерактивных пользовательских интерфейсов для анализа данных через Earth Engine. То есть, ваш готовый код в Earth Engine JavaScrip API можно обернуть в графическое приложение с простыми элементами интерфейса, которое потом могут использовать рядовые пользователи, не взаимодействуя с кодом напрямую.

Приложения, опубликованные в качества Earth Engine Apps, доступны по URL-адресу, созданному во время публикации приложения. Для просмотра или взаимодействия с опубликованным приложением учётная запись Earth Engine не требуется. Чтобы оценить возможности Earth Engine Apps, вы можете посмотреть на галерею избранных приложений.

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

Earth Engine Apps могут принимать различные формы на основе виджетов, панелей и макетов, выбранных вами из API пользовательского интерфейса.

3.2. Расширение для QGIS

С недавнего времени интеграция с Earth Engine появилась и в QGIS — одной из самых популярных ГИС в мире, которая к тому же является проектом с открытым исходным кодом. Интеграция реализована на основе плагина QGIS Earth Engine, который «подключает» Earth Engine к QGIS с помощью Earth Engine Python API. Работа над этим расширением ведётся сторонними разработчиками, не связанными с Google. В настоящий момент плагин активно развивается, но реализует лишь небольшую часть функционала платформы. Однако он имеет очевидные преимущества за счёт вывода данных непосредственно в QGIS.

Пример интеграции Earth Engine и QGIS на основе стороннего расширения QGIS Earth Engine, работающего через Earth Engine Python API.

4. Примеры проектов на основе Earth Engine

Earth Engine используется в самых разных дисциплинах, охватывающих такие темы, как:

• Глобальное изменение лесов
• Глобальное изменение поверхностных вод
• Оценка урожайности
• Картирование рисовых полей
• Картографирование городских территорий
• Картирование наводнений
• Оценка восстановления территорий после пожаров
• Картирование риска малярии
• Защита ареалов обитания животных

А вот несколько примеров использования Earth Engine от авторов статьи:

• COVID-19 Lockdown Cleans Polluted Air in Italy — мы использовали платформу Earth Engine для изучения связи между уменьшением загрязнения воздуха и мер, принимаемых правительствами разных стран, из-за пандемии коронавируса. Пока ещё рано говорить о каких-то конкретных закономерностях, но выявление взаимосвязей между благосостоянием человека и характеристиками окружающей среды — очень перспективное направление.

Интерфейс веб-приложения CompareNO2, основанного на Earth Engine, которое мы разрабатываем в Российском университете дружбы народов. Оно позволит оценивать динамику выбросов диоксида азота в разных регионах мира.

• Space-based monitoring capabilities for the evaluation of inland water resources: Application to Nigeria — благодаря анализу огромного количества снимков космической программы Landsat в Earth Engine нам удалось с высоким разрешением оценить, как менялась площадь поверхностных вод Нигерии с 1984 года.

По всему миру разработчики интегрируют платформу Earth Engine в сторонние приложения и геопорталы:

• Global Forest Watch — портал для интерактивного анализа и оперативного вычисления сводных статистических данных по лесному покрову. Тысячи людей во всем мире используют GFW каждый день для мониторинга и управления лесами, прекращения незаконной вырубки лесов, выявления пожаров, защиты своих земель и ресурсов и обеспечения устойчивого развития.
• Climate Engine — портал для обработки спутниковых и климатических данных по запросу через веб-браузер. Он позволяет отображать климатические аномалии, временные ряды и статистические сводки, созранять результаты в формате GeoTIFF или в виде таблиц.
• Collect Earth — это основанный на Java инструмент для оценки изменений в землепользовании. Он использует интерфейс Google Earth в сочетании с формой ввода данных на основе HTML. Формы могут быть адаптированы для соответствия схемам классификации по конкретной стране в соответствии с руководящими принципами различных международных организаций.
• Map of Life — портал географической информации о биоразнообразии, детально показывающий ареалы обитания различных видов.

5. Справка и обучение

• Справочная информация по API Earth Engine
• Короткие руководства (Guides) по конкретным прикладным темам от разработчиков
• Официальные обучающие материалы (Tutorials) от разработчиков
• Earth Engine resources for higher education — обучающие материалы от ведущих мировых университетов, среди которых есть и методические указания на русском языке, разработанные авторами этой статьи
• earthengine-py-notebooks — репозиторий на GitHub, в котором собрано более 360 «блокнотов» Jupyter Notebooks с образцами использования Earth Engine API на Python
• EE101 Condensed: Fast start to the Earth Engine API — этот семинар, проведённый Ноэлем Гореликом, одним из разработчиков платформы, быстро познакомит вас Earth Engine API

6. Поддержка

6.1. Сообщество пользователей

• Конкретные технические вопросы задаются на GIS Stack Exchange (тег «google-earth-engine»). Там довольно активные пользователи. Мы заметили также, что на вопросы часто отвечают сами разработчики Earth Engine.
• Вопросы общего характера для обсуждений (например, о дистанционном зондировании или какой-то методологии), задаются на форуме разработчиков Earth Engine.

6.2. Связь с разработчиками

6.2.1. Сообщения об ошибках редактора кода

Любой отзыв по проблемам с отображением интерфейса и функциональностью редактора кода отправляется через кнопку Feedback→Send Code Editor feedback. Появится окно, позволяющее вам описать проблему. Также можно будет сделать скриншот, чтобы выделить место возникновения ошибки.

Все запросы на исправление ошибок API (ошибки скрипта или выдача неверных результатов), добавление новых данных или улучшение платформы осуществляются через IssueTracker — cистему отслеживания задач и ошибок.

6.2.2. Сообщения об ошибках API

1. Сначала ищите свою ошибку в списке багов — возможно, кто-то уже о ней сообщил.
2. Если это так, то поставьте «звёздочку» напротив ошибки: это повысит её ранг. Откройте её и напишите, как она влияет на ваш рабочий процесс. Ваш отзыв поможет разработчикам быстрее её исправить.
3. В случае, если соответствующая ошибка не существует в списке, добавьте новую.

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

6.2.3. Запросы на добавление новых наборов данных

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

1. Сначала поищите искомые данные в списке существующих запросов на добавление.
2. Если вы найдёте соответствующий запрос данных в списке, то отметьте его проставлением «звёздочки», после чего откройте его и добавьте комментарий о том, как этот набор данных будет полезен в вашей работе.
3. Если запроса на искомые данные ещё нет, то создайте новый.

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

6.2.4. Запросы новых возможностей редактора кода и API

1. Поищите среди существующих запросов новых возможностей.
2. Если такой запрос уже есть, то отметьте его «звёздочкой» и добавить к нему свой комментарий.
3. Если такого запроса нет, то создайте новый, детально описав, что вы хотите.

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

7. Альтернативы Earth Engine

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

Например, Sentinel Hub с примечательным функционалом Sentinel Playground, позволяет отображать маршруты Sentinel-2 на выбранную дату на интерактивной web-карте, а также осуществлять «на лету» операции растровой алгебры со спектральными каналами изображений.

Кроме того Европейская комиссия в 2017 году запустила инициативу по развёртыванию пяти облачных платформ для облегчения и стандартизации доступа к своим спутниковым данным. Эти платформы обеспечивают централизованный доступ к спутниковой информации программы Copernicus, а также к инструментам обработки данных. Они известны под общим названием DIAS (Data and Information Access Service — службы доступа к данным и информации):

1. ONDA DIAS
2. CREODIAS
3. Mundi
4. Sobloo
5. Wekeo

Все они основаны, что очевидно, на данных Европейского космичекого агентства. По количеству наборов данных они не сравнимы с каталогом Earth Engine, в котором также есть изображения с европейских спутников. Однако ориентированность под конкретную программу Copernicus даёт больше возможностей по использованию этой информации, включая специализированное программное обеспечение и доступ к разным уровням обработки спутниковых снимков. Следует также отметить коммерческую направленность всех указанных выше платформ, что сильно отличает их от Earth Engine.

8. Итог

Мониторинг, управление и защита окружающей среды являются важнейшими и сложнейшими задачами, стоящими перед человечеством, а эффективный анализ данных является ключом к их решению. Активное развитие геоинформационных систем и дистанционного зондирования Земли привело к накоплению большого объёма структурированной информации. Вместе со значительным прогрессом в сфере облачных вычислений это создало условия для появления облачных платформ обработки больших геоданных, самая известная из которых на сегодняшний момент — Google Earth Engine. Она объединяет петабайты спутниковых изображений и наборов геопространственных данных в одном каталоге, предоставляя возможности для их анализа в планетарном масштабе. При этом сама платформа является открытой и бесплатной для некоммерческого использования.

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

С уверенностью можно утверждать одно: появление платформ для обработки больших геоданных, подобных Google Earth Engine, позволяет решать геоинформационные задачи принципиально нового уровня сложности, недоступного ранее.

Этот материал подготовлен преподавателями Инженерной академии Российского университета дружбы народов Василием Лобановым и Ярославом Васюниным.

Автор: Василий Лобанов

Источник