Estoy tratando de usar PostGIS 2.0 en Postgres 8.4 para hacer algunos mapas. Estoy trabajando con los Shapefiles de la NOAA, específicamente su archivo de Estados y Territorios de los Estados Unidos ubicado aquí:
http://www.nws.noaa.gov/geodata/catalog/national/html/us_state.htm
La aplicación que estoy construyendo necesita hacer pruebas de polígono en polígono, y pruebas de punto en polígono (PiP). Los shapefiles tal como están son demasiado detallados, y las consultas están tomando demasiado tiempo. Estoy tratando de conseguir que PostGIS simplifique las complejas formas de los estados, quiero lograr una alta calidad de envoltura de cada estado, de modo que los ríos y las bahías se incluyen en los estados, pero las pequeñas islas costeras u otras masas terrestres diminutas se ignoran . Mi objetivo es tener dos tablas: tanto la tabla de geometrías crudas de los estados para situaciones de salida de alta calidad, y también una tabla separada states_simple donde puedo usar geometrías pre-comprimidas para acelerar las pruebas PiP.
Finalmente he descubierto cómo implementar correctamente ST_Concavehull, pero me encuentro con los límites del hardware del servidor, o la configuración de postgres.
Aquí hay una imagen para ilustrar el problema que me encuentro:
El procesamiento de estados "cuadrados" como Oklahoma mediante el proceso ConcaveHull es rápido y sin problemas. Los estados que tienen ALGUNAS islas costeras/complejidad como Georgia procesan un poco más lento, pero razonablemente rápido y salen de una manera que será útil para la prueba PiP (es decir, una envoltura apretada):
Sin embargo, algunos estados como Nueva Jersey están mostrando algunos de los mismos problemas que tiene Florida al utilizar ConcaveHull:
La parte superior e inferior de Nueva Jersey son EXACTAMENTE lo que quiero, pero la gran parte de Pensilvania, incluida Filadelfia, y la inclusión de Staten Island básicamente hacen que esta geometría sea inútil para mis propósitos.
Así que ahora mismo la consulta que estoy utilizando para recuperar estos polígonos es la siguiente (el ejemplo es FL):
SELECT ST_AsGeoJSON(ST_ConcaveHull(ST_Union(geom),.4)) as geom FROM states WHERE id = 11;tl;dr:
Si reduzco la tolerancia de 0,4 a algo así como 0,6, el estado sale como un triángulo gigante. 0,4 parece ser el límite inferior de ConcaveHull, cualquier cosa inferior a eso y las consultas se ejecutan durante más de 3 minutos sin devolver resultados.
He estado siguiendo este artículo para obtener consejos y pasos para aumentar el rendimiento de Postgres y PostGIS:
http://postgis.net/workshops/postgis-intro/tuning.html
Cambios que he hecho en postgresql.conf:
- shared_buffers = 256MB
- work_mem = 16MB
- wal_buffers = 1MB
- segmentos_de_control = 6
- coste_de_página_aleatorio = 2,0
El servidor en el que se está ejecutando todo esto es un servidor LAPP Linux llave en mano que se ejecuta en una instancia de Amazon EC2 Medium M1 (64 bits, 1cpu, 3.75gb RAM)
¿Estoy haciendo todo mal? ¿Hay algún otro conjunto de estados CONUS "más suaves" que pueda utilizar? Tengo la teoría de que el tamaño relativo (léase: enorme) de las geometrías de los estados es lo que está atascando a PostGIS/Postgres... pero no estoy muy seguro de cómo diagnosticar o supervisar eso más allá de ejecutar
ps aux | grep ^ postgresy ver el tiempo que tardan las consultas en ejecutarse.
Mis principales preguntas:
- ¿Cómo puedo controlar mejor el uso de recursos de este proceso?
- ¿Estoy utilizando las funciones correctas de PostGIS para lograr este objetivo?
- ¿Es cuestión de bajar la tolerancia de ConcaveHull, y aumentar los límites del sistema?
