Растровые данные в PostGIS для хранения/анализа данных

[kaa]

Добрый день, выложил статью для обсуждения: Растровые данные в PostGIS для хранения/анализа данных на решетке

[SergeyRyzhkov]

Уважаемый kaa, отлично что Вы начали писать! Я уже думал позабылось
Ссылка прока не рабочая (или может я не так что-то делаю?)

[paleogis]

Ссылка прока не рабочая (или может я не так что-то делаю?)

Ссылку поправил.

[SergeyRyzhkov]

kaa,
А вы можете приложить небольшой пример исходного файла?
Чтобы видеть формат

[Ariki]

Так в статье ж ссылка на источник данных.
А вот ссылки на документацию по данным не хватает.

[SergeyRyzhkov]

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

Ессно не претензия это к статье, просто моя хотелка, как интересующегося

[kaa]

С документацией там не очень. Есть описание предыдущего формата ftp://ftp.cpc.ncep.noaa.gov/precip/glob ... 8km-hourly и отличия от него нового ftp://ftp.cpc.ncep.noaa.gov/precip/glob ... -LOCATIONS

[Александр Мурый]

Спасибо, что всё-таки решились написать заметку по этой интересной теме.
Сразу замечания:
- название не совсем соответствует содержанию (слишком широко названо, а у вас конкретная задача для конкретных данных); может, лучше как-то так - "Пример использования PostGIS для хранения и обработки растровых данных"?
- хотелось бы больше примеров анализа, 1 пример - это всё-таки маловато.

[bim2010]

Затем с помощью него из исходного файла формируется GeoTIFF (с параметрами компресии):
gdal_translate -co TILED=YES -co INTERLEAVE=BAND -co COMPRESS=LZW cmorph.vrt cmorph.tif

Каков размер файла GeoTIFF ?

Попытка развертывать исходные данные в векторный тип не очень обнадежила.

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

[kaa]

> может, лучше как-то так - "Пример использования PostGIS для хранения и обработки растровых данных"?
переименовал: Пример использования PostGIS для хранения и обработки растровых данных

> Каков размер файла GeoTIFF ?
около 600кб, добавил в текст

> Утверждение спорно. Не стоит это писать в статье. Про нормализацию данных уже писали.
нормализация не помогает, в статье про это есть
<pre>
Следующая попытка заключалась в разнесении данных о координатах узлов решетки и значений узлов по разным таблицам:
...
Это ситуацию улучшило, но не кардинально. Таблица с координатами занимала все равно 1gb, но каждый срез обходился уже всего в 400mb.
</pre>

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

[SergeyRyzhkov]

kaa, прежде всего спасибо за работу!
Еще помучаю Вас.

1. Дополните как Вы получили VRT после "Сперва формируется VRT файл" ...
Я вот с удивлением узнал что можно так просто подсунуть указанный файл CMORPH_V0.x_RAW_8km-30min_2015050519
в качестве источника данных
Также можно кратко написать почему выбраны те или иные параметры

2. Можно пару слов о параметрах команды gdal_translate (Вам вроде советовали почему да как)


ЗЫ: Мелочь. Я бы фразу:
" ... чтобы потом решать поставленные задачи простыми вызовами PostGIS SQL ..."
заменил на
" ... чтобы потом решать поставленные задачи выполнением SQL - запросов к PostGIS ..."

[Ariki]

Упоминается, что в файле CMORPH два временных среза, а в VRT описан один.

Опции создания GeoTIFF в данном случае не критичны: всё равно в итоге всё заливается в базу. Только COMPRESS=LZW полезен: сжатие сильно уменьшает размер промежуточного файла и ускоряет его обработку.

Другое дело - если этот TIFF предполагается непосредственно просматривать, например, в QGIS. Но тогда ещё и пирамиды надо построить.

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

Кстати, последний пример кода SQL хорошо бы отформатировать на несколько строчек: легче будет читаться.

ЗЫ: Мелочь. Я бы фразу:
" ... чтобы потом решать поставленные задачи простыми вызовами PostGIS SQL ..."
заменил на
" ... чтобы потом решать поставленные задачи выполнением SQL - запросов к PostGIS ..."

Действительно, мелочь, вдобавок мне вариант автора больше нравится.

[SergeyRyzhkov]

Насчет создания виртуального каталога, я бы упомянул откуда взялся параметр
<GeoTransform>0.036378335, 0.072756669, 0.0, -59.963614, 0.0, 0.072771377</GeoTransform>

ЗЫ: Насчет мелочи. Да действительно мелочь. Прост режет немного "вызовами PostGIS SQL". Нет такого. SQL диалект сам по себе )) .Ну ладно, мелочь.

[SergeyRyzhkov]

Дополнительно.
Если растр очень большой. Есть ли смысл строить tif предварительно ? (если он не планируется к дальнейшему использованию).
Вроде как для raster2pgsql в качестве источника можно сразу указывать VRT (сам не пробовал)

ЗЫ: Опять мелочь.
Как-то странно фраза звучит:
"Полученный растр можно загрузить в PostGIS подготовив SQL вызовом"

[Ariki]

Да, шаг с формированием GeoTIFF лишний, лучше грузить напрямую.

Как-то странно фраза звучит:
"Полученный растр можно загрузить в PostGIS подготовив SQL вызовом"

Ну запятая пропущена. Имеется в виду, что вызов команды генерирует скрипт SQL, который потом следует выполнить для загрузки растра. Кстати, только сейчас заметил, в команде не указано, куда перенаправить её вывод - надо добавить и объяснить значение параметров (они не очевидны).