Форумы GIS-Lab.info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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