[Open source, Программирование, Геоинформационные сервисы, Визуализация данных, Научно-популярное] Google Earth Engine (GEE) как общедоступный суперкомпьютер

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
22-Мар-2021 15:32

Цитировать

Сервис Google Earth Engine предоставляет возможность бесплатно работать с огромными массивами пространственной информации. К примеру, в считанные минуты можно получить композитную мозаику (сборное изображение) по миллиону космоснимков. Считая, что каждая сцена (набор спектральных каналов) Landsat 8 занимает в сжатом виде 1 ГБ, при таком запросе обрабатывается объем информации порядка 1 ПБ. И все это доступно бесплатно, быстро, и в любое время. Но есть такое мнение (неправильное), что GEE на бесплатных аккаунтах позволяет обработать и экспортировать лишь небольшие наборы данных. На самом деле, такое впечатление вызвано лишь тем, что программировать на GEE можно начать, даже не читая документации сервиса, а вот извлечь много данных, все еще не читая документации, уже не получится. Далее мы рассмотрим три разных решения задачи векторизации растров и двумя разными способами напишем серверную GEE функцию для вычисления геохэша.

Введение
А вы любите работать на суперкомпьютерах (это университетские кластеры, к примеру)? Я — нет! Несмотря на всю их мощь, на практике зачастую полезность таких монстров совсем не очевидна. Вы можете меня упрекнуть в пристрастности (и это правда — для меня линукс дебиан, конечно, лучший, и убунта как его непутевый потомок тоже на что-то годится), но работать на околодесятилетней давности линуксе центос это совсем перебор (он и свежий-то всегда второй свежести, если глянуть на версии пакетов в нем). Впрочем, это еще цветочки. Чтобы зря не тратить драгоценные ресурсы суперкомпьютеров, на них обычно установлен коммерческий компилятор интел, притом очень мохнатого года (может быть старше самого центоса, который, видимо, когда-то уже обновляли). Но и это еще не беда, в конце концов. Планировщики ресурсов на таких системах часто вызывают оторопь, и есть с чего — при попытке запустить задание, скажем, на 128 ядрах, ничего не происходит, ни запуска задания, ни выдачи какой-либо ошибки от утилиты запуска. В процессе оказывается, что число доступных нам ядер равно двум (всегда удивляюсь, почему так мало по умолчанию дают ресурсов), увеличение квоты требует административной работы (зачастую, уже на этом этапе проще переключиться на какой-нибудь Amazon AWS). Но самое худшее начинается позже. С завидным постоянством бинарные модули того самого вышеупомянутого проприетарного компилятора оказываются установлены в домашней директории давно сгинувшего вместе со своей домашней директорией пользователя, а без них компилятор, естественно, ничего не компилирует. Конечно, другого компилятора в системе нет, ведь его код был бы не столь оптимален… Таким образом, ситуация проясняется — нам нужно найти подходящий центос, установить его где-то локально или в облаке, портировать на него нужный софт, сделать статические сборки (поскольку на целевой системе часть системных пакетов может быть заменена непонятно чем и откуда) и тогда, возможно, мы сможем все это запустить на доступных нам двух ядрах кластера (будет ли когда-нибудь доступно большее их количество — предугадать невозможно, по разным причинам). Я мог бы еще многое добавить, но вы уже понимаете, почему лично я не люблю суперкомпьютеры.
Теперь поговорим про другой суперкомпьютер — облачный и общедоступный сервис Google Earth Engine. Все, что нам потребуется для начала работы — открыть ссылку в браузере и можно начинать писать код на javascript и скачивать данные (кстати, можно туда загрузить еще и свои данные, а еще можно использовать API сервиса для доступа из других сред разработки и языков). При этом сразу же доступно огромное количество данных и вычислительных ресурсов. На мой взгляд, все это вполне заслуживает того, чтобы почитать-таки документацию и научиться работать в сервисе достаточно эффективно. Впрочем, обработка и получение растров достаточно очевидны и так, тем более, что ко всем предоставляемым в сервисе наборам данных есть и примеры их визуализации, а для их скачивания на Google Drive (к примеру) в растровом формате (обычно, GeoTIFF) достаточно функции Export.image.toDrive. А вот работа с векторными данными, тем более, преобразование растров в вектор далеко не так очевидны и в интернет зачастую можно встретить жалобы, что не удается выгрузить несколько сот тысяч записей. Вот специально сейчас проверил — за 21 минуту мне удалось выгрузить 10 миллионов записей на Google Drive в формате GeoJSON, получив файл размером 2Гб. И это далеко не предел для бесплатного аккаунта (не говоря уж о том, что можно выгружать данные по частям).
Преобразование растровых данных сервиса в точечные
Рассмотрим три подхода:

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

var points_with_attributes = Image.reduceRegion({
reducer: ee.Reducer.toList(Image.bandNames().size()),
geometry: points
})

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

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

var attributes = Image.reduceRegion({
reducer: ee.Reducer.toList(Image.bandNames().size()),
geometry: some_area
})

Метод рабочий, но с подвохом и ресурсоемкий. В чем же подвох? Дело в том, что в некоторых точках растра атрибутивные данные могут быть пропущены и такие точки исключаются в данном методе. То есть метод возвращает от нуля до полного набора точек, которые попадают в заданную область. И как только мы захотим получить и координаты возвращаемых точек, метод может перестать работать (если в данных есть пропуски, как отмечено выше). Посмотрим код примера:

var latlon = ee.Image.pixelLonLat()
var points_with_attributes = image
.addBands(latlon)
.reduceRegion({
reducer: ee.Reducer.toList(),
geometry: some_area
});

Функция ee.Image.pixelLonLat() создает растр с координатами каждой точки, который мы добавляем к рабочему растру. Этот код прекрасно работает, но только пока в растровых данных нет пропусков и длины списков координат и атрибутов совпадают. Кроме того, необходимо добавить перепроецирование данных, но эта операция ресурсозатратная и сильно ограничивает наши возможности обработки данных на бесплатном аккаунте:

var latlon = ee.Image.pixelLonLat().reproject(image.projection())
var points_with_attributes = image
.addBands(latlon)
.reduceRegion({
reducer: ee.Reducer.toList(),
geometry: some_area
});

К счастью, возможно разом решить обе проблемы:

var latlon = ee.Image.pixelLonLat()
var points_with_attributes = image
.addBands(latlon)
.add(image.select(0).add(0))
.reduceRegion({
reducer: ee.Reducer.toList(),
geometry: some_area
});

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

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

var latlon = ee.Image.pixelLonLat()
var points_with_attributes = image
.sample({
region: some_area,
geometries: true
});

В коде выше флаг "geometries" указывает, нужны ли нам координаты точек или только их атрибуты.
Создание собственных серверных функций
Обычно, кроме извлечения данных "как есть", мы еще хотим как-то их обработать. Это можно сделать локально, выгрузив данные, или непосредственно в сервисе GEE. Во втором случае, мы получаем огромные вычислительные ресурсы, но нужно написать специальный код для серверной обработки. Следует помнить, что в окне облачного редактора мы можем писать смесь клиентского и серверного кода (что часто приводит к различным ошибкам). Когда вы только начинаете писать серверные функции GEE, нужны рабочие примеры, но найти их сложно. Для примера напишем функцию вычисления геохэша, или хэша заметающей кривой (z-curve). Кстати, найти готовую реализацию такой функции мне не удалось, что еще раз подтверждает, как сложно начинающим найти примеры по серверным функциям GEE. Чем полезна такая функция? Кроме прочего, геохэш позволяет сделать пространственное объединение данных очень просто и без операций с геометрическими объектами — достаточно лишь сократить количество символов геохэша. Кодирование и декодирование геохэшей поддерживается в PostgreSQL/PostGIS, Google BigQuery и многих других системах. Итак, посмотрим простую реализацию функции в стиле С-кода:

Сделаем также простую проверку полученных геохэшей

// PostGIS check from https://postgis.net/docs/ST_GeoHash.html
print (ee.Algorithms.If(geohash_encode(48, -126, 20).compareTo('c0w3hf1s70w3hf1s70w3'),'Error','OK'));
// Google BigQuery check from https://cloud.google.com/bigquery/docs/reference/standard-sql/geography_functions#st_geohash
print (ee.Algorithms.If(geohash_encode(47.62, -122.35, 10).compareTo('c22yzugqw7'),'Error','OK'));

Вместо использования вложенных циклов в функции geohash_encode() мы создаем функцию geohash_accumulate() и вызываем ее 5 раз для вычисления каждого символа геохэша. С учетом того, что GEE лимитирует количество вызовов функций, это не слишком масштабируемое решение. Как можно улучшить функцию? Проще всего продублировать пятикратно участок кода под комментарием "calculate substep bit step idx" и вызывать полученную функцию geohash_accumulate() лишь единожды для каждого вычисляемого символа (при желании, можно также сократить количество передаваемых между вызовами переменных). А можно и переписать код внутренней функции в функциональном стиле. Я, в общем-то, и не собирался этого делать, но пока я писал текст статьи, мне стало интересно попробовать и вот что получилось:

Да, это та же самая функция, только уже в Javascript-стиле, и требует в пять раз меньше вызовов внутренней функции, что позволит нам обработать примерно впятеро раз больше данных на бесплатном аккаунте.
Заключение
Сегодня мы рассмотрели еще кусочек мозаики из мира пространственной обработки данных. Как обычно, я рассказал о том, что бесплатно доступно каждому и легко может быть повторено, поскольку весь код перед вами. Конечно, и этот код будет доступен на моем GitHub (смотрите репозиторий GIS Snippets в поддиректории GEE). Сразу не выложил, поскольку там надо сначала порядок навести — оказывается, чего у меня только не накопилось за два десятилетия работы с пространственными данными и программирования вообще.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_open_source, #_programmirovanie (Программирование), #_geoinformatsionnye_servisy (Геоинформационные сервисы), #_vizualizatsija_dannyh (Визуализация данных), #_nauchnopopuljarnoe (Научно-популярное), #_earth_engine, #_javascript, #_supercomputing, #_open_source, #_programmirovanie (
Программирование
), #_geoinformatsionnye_servisy (
Геоинформационные сервисы
), #_vizualizatsija_dannyh (
Визуализация данных
), #_nauchnopopuljarnoe (
Научно-популярное
)

Профиль ЛС

Ответить на тему

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

Текущее время: 25-Ноя 06:14
Часовой пояс: UTC + 5