PostGIS для хранения данных на решетке

[kaa]

Добрый день! Возникла задача оперировать данными, которые привязаны к пространственной решетке. Данные о которых идет речь берутся отсюда ftp://ftp.cpc.ncep.noaa.gov/precip/CMOR ... 8km-30min/ . Это данные об осадках, которые для определенной временной точки записаны в файл как развернутый 2-мерный массив вещественных чисел. Для каждого элемента массива по строке и столбцу можно определить геокоординаты точки, для которой он рассчитан. Примеры задач которые требуется решать:
1) определить среднее значение показателя для замкнутой области
2) определить среднее значение показателя для замкнутой области для требуемого временного интервала (т.е. просуммировав точки по нескольким файлам)
3) сформировать растровую карту для отображения суммарных значений для требуемого временного интервала (т.е. просуммировав точки по нескольким файлам)

Понятно, что все эти задачи можно решать напрямую, читая данные из файлов, суммируя значения.
А может ли для этой задачи помочь PostGIS? Можно ли как то представить подобные данные как растровую карту, чтобы потом решать поставленные задачи простыми вызовами PostGIS SQL?
Из документации PostGIS понятно что он может работать с предопределенными типами растровых данных. Можно ли как то сформировать растр для произвольных вещественных чисел в узлах решетки? Какой формат лучше для этого использовать?

[Максим Дубинин]

у вас растры, PostGIS для векторных данных кроме нескольких особых ситуаций, тут он вам не нужен совершенно

используйте R, GRASS, QGIS с инструментами

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

Если хочется именно БД, может быть, попробовать экзотику типа rasdaman? Вот описание на русском и начало работы.

[kaa]

БД хочется чтобы можно было быстро получать результаты расчетов для большого числа одновременных запросов и отображать средние значения и карты на вэб клиенте. Попытка развертывать исходные данные в векторный тип и затем считать интерполяцией растр на лету с помощью GeoServer не очень обнадежила. Один временной разрез отображается в ~10M строк в PostGIS, что приводит к чудовищному размеру базы. Поэтому и возник вопрос про хранение в растре.

[SergeyRyzhkov]

А каким способом в БД вы уже пробывали? просто использовать таблицу,без всяких геометрий и тд. Обьем данных большой,конечно,но для СУБД это мелочи

[ Сообщение с мобильного устройства ]

[kaa]

В бд клал в таблицу для каждой точки id, дату, значение показателя и положение POINT. На положение соответственно GIST индекс. Для среза из 7.8M точек получается таблица 1150MB на диске из которых 500MB индекс.
Кстати если вместо геометрии хранить просто положение точки в решетке(int x и int y) то ситуацию это не улучшает, все равно размер под гигабайт из которых половина - индекс.

Поэтому и появилась мысль о растре, он по идее должен существенно экономнее хранить данные на равномерной решетке.

[SergeyRyzhkov]

Я бы (на вскидку) сделал так (разнес бы две сущности, то есть провел бы нормализацию):

1. Отдельная таблица определяющую сетку (узлы).
Идентификатор
Геометрия точки
Индекс естественно пространственный

2. Отдельная таблица для значений
Идентификатор
Внешний ключ на табл 1
Дата измерения
Значение

3. Далее соотв. хранимые процедуры для получения ....

Должно помочь с размером, так как убираете дубли.

[nickleb]

м.б., посмотреть, действительно, в сторону Array DataBases... м.б., MonetDB?:
www.nesc.ac.uk/talks/1130/SciQLintro_Kersten.pdf

[SergeyRyzhkov]

А какая разница в какую сторону смотреть? Если данные по ячейке весят 1К, хоть куда весь набор засунуть,сумма не изменится.
Скорее вопрос к архитектуре данных

[ Сообщение с мобильного устройства ]

[kaa]

По ячейке если не брать во внимание координаты и время(общее для всего снимка) хранится одно вещественное число, то есть теоретически размер снимка из 10м точек может укладывться в 40мб. Поэтому появилась идея хранить снимок как один растр (1запись) а требуемые значения получать применяя ST_Clip для обрезки области а затем вычислять какой нибудь функцией среднее значение. Вот только я не смог понять как сформировать растр из этой решетки.

[SergeyRyzhkov]

Классический вариант описания grid я вам выше привёл. Не подходит? Возможно для вашей задачи нужны другие решения. Может дадите кусок данных и более чётко опишите задачу конечную?

[ Сообщение с мобильного устройства ]

[nickleb]

....Данные о которых идет речь берутся отсюда ftp://ftp.cpc.ncep.noaa.gov/precip/CMOR ... 8km-30min/ . Это данные об осадках, которые для определенной временной точки записаны в файл как развернутый 2-мерный массив вещественных чисел. Для каждого элемента массива по строке и столбцу можно определить геокоординаты точки, для которой он рассчитан.
...читая данные из файлов, суммируя значения.

а Вы эти данные через NCL читаете?

www.ncl.ucar.edu/

Если их ещё и в NetCDF4-"одёжку" одеть, - дело веселее пойдёт (через тот же NCL или в R посредством package'а "ncdf4" cran.r-project.org/web/packages/ncdf4/index.html ) - так кажется - сам-то не пробовал, но вот собираюсь попробовать...

[kaa]

> а Вы эти данные через NCL читаете?
нет, просто читаю данные из файла стандартным образом
> Классический вариант описания grid я вам выше привёл. Не подходит?
попробовал, вместо 1гб один срез занимает 400мб. все равно многовато
>Может дадите кусок данных и более чётко опишите задачу конечную?
Данные одного среза это массив 4948 x 1649 4х байтовых вещественных чисел рассчитанных для сетки с шагом 0.072756669 по долготе и 0.072771377 по широте начиная от 0.036378335E, 59.963614N.

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

[Ariki]

Я бы в таком случае порезал растр на прямоугольные тайлы. В PostGIS бы хранил геометрию тайла и предрассчитанное среднее по каждому показателю. Сами тайлы можно хранить в файловой системе, можно и в БД: каждый тайл как бинарный объект, который можно прочитать целиком. Хорошей идеей будет кэширование в оперативной памяти.
При расчёте среднего для области делается выборка по геометрии из базы тайлов. Для тех тайлов, что попадают в область целиком, берётся предрассчитанное среднее. Для тех, которые попадают частично, область пересечения растеризуется и используется в качестве маски для расчёта среднего непосредственно по растровому тайлу. Чтобы получить среднее по всей области, средние значения по тайлам агрегируются с учётом площадей пересечения. Надеюсь, понятно объяснил.
Но если типичная область для расчёта среднего невелика, можно поступить по-другому: хранить растр в tiled GeoTIFF и делать для расчёта выборку по ограничивающему прямоугольнику. Тайловая организация файла TIFF (флаг TILED=YES в GDAL) позволяет читать растровые данные не построчно, а прямоугольными блоками, что для большинства задач в ГИС более эффективно. Размер блока можно задать при создании файла.

[nickleb]

"Надеюсь, понятно объяснил."

Понятно, занятно, красиво, поучительно - Век живи- Век учись. Спасибо.