Aceleración del muestreo de puntos con la función ST_Value en PostGIS, superposición de ráster/vector

Question

He conseguido extraer valores ráster en PostGIS a partir de una tabla de geometrías de puntos de la siguiente forma Raster de muestreo de puntos con PostGIS

SELECT id, ST_Value(rastertable.rast, 1, pointtable.geom) as RasterValue
FROM rastertable, pointtable
WHERE ST_Intersects(rastertable.rast, pointtable.geom)
LIMIT 20

La consulta anterior tarda unos 20 segundos, es decir, un segundo por caso. Al final quiero extraer los valores raster de más de 10 millones de puntos. Con la consulta actual, tardaría unos 115 días, lo que no es una opción viable. ¿Cómo podría ajustar la consulta anterior para aumentar el rendimiento? ¿O incluso tendría que cambiar el método?

Editar: Usando el plugin de muestreo de puntos de QGIS también se consigue una velocidad de 3 segundos por cada 10 puntos, reduciendo el tiempo de espera a unos 40 días. Eso sigue siendo inviable.

Información sobre la versión:

Answer 1

Me enfrentaba a los mismos problemas que tú, y simplemente pasando de 1000x1000 a 100x100 menos a un aumento de velocidad de varios órdenes de magnitud. Con el fin de mosaico de su trama de entrada utilizar el -t switch en raster2pgsql, eg,

raster2pgsql -t 200x200 -I -s .......

Tengo entendido que Valor_ST funciona como un desplazamiento en una matriz (2D o 3D, dependiendo de las bandas) y que como cada trama individual se almacena como una mancha, tendrá que abrir cada una para encontrar el píxel en x, y o que se cruza con una geometría. Por lo tanto, se deduce que los mosaicos más pequeños conducen a búsquedas más rápidas, sobre todo porque la estructura del índice será cajas muy equilibradas.

Evidentemente, existe un punto óptimo para el tamaño de los mosaicos, que dependerá de la forma de ST_Value que se utilice y de la carga de trabajo en cuestión: yo esperaría que los polígonos se comportaran de forma muy diferente a los puntos. Hay algunos buenos consejos en esta entrada del blog de Duncan Golicher que muestra un descenso continuo de la velocidad a medida que disminuye el tamaño del mosaico para las búsquedas de puntos y un descenso inicial con los polígonos, con un punto dulce en torno a 150, antes de volver a aumentar, lo que a priori tiene sentido.

He aquí un par de imágenes del post de Duncan que ilustran este punto.

Me encontré con que de vez en cuando recibía un error de ST_Value acerca de las búsquedas fuera de los límites de la trama y, finalmente, utiliza ST_NearestValue con las mismas características de rendimiento.