ST_Intersection lento de la consulta

Question

Estoy tratando de realizar una intersección entre dos capas:

1. Polilínea en la capa de representación de algunas carreteras (~5500 filas)
2. Capa de polígonos que representan de forma irregular búferes en torno a varios puntos de interés (~47,000 filas)

En última instancia, lo que yo estoy tratando de hacer es de clip de la polilíneas a muchos de estos (que a veces se solapan) los topes, y luego resumir la longitud total de la carretera dentro de cada búfer.

El problema es que las cosas están funcionando LENTO. No estoy seguro de cuánto tiempo debe tomar, pero yo sólo abortado a mi consulta después de > 34 horas. Estoy esperando que alguien puede señalar donde tengo un error con mi consulta de SQL, o puede que me señale una mejor manera de hacer esto.

CREATE TABLE clip_roads AS

SELECT 
  ST_Intersection(b.the_geom, z.the_geom) AS clip_geom,
  b.*

FROM 
  public."roads" b, 
  public."buffer1KM" z

WHERE ST_Intersects(b.the_geom, z.the_geom);


CREATE INDEX "clip_roads_clip_geom_gist"
  ON "clip_roads"
  USING gist
  (clip_geom);



CREATE TABLE buffer1km_join AS

SELECT
  z.name, z.the_geom,
  sum(ST_Length(b.clip_geom)) AS sum_length_m

FROM
  public."clip_roads" b,
  public."buffer1KM" z

WHERE
  ST_Contains(z.the_geom, b.the_geom)

GROUP BY z.name, z.the_geom;

Tengo una idea índice creado por los caminos originales de la tabla, y (sólo para estar seguro?) crear un índice antes de hacer la segunda creación de la tabla.

El plan de consulta de PGAdmin III se parece a esto, aunque me temo que no tengo mucha habilidad en la interpretación de:

"Nested Loop  (cost=0.00..29169.98 rows=35129 width=49364)"
"  Output: st_intersection(b.the_geom, z.the_geom), b.gid, b.geo_id, b.address_l, b.address_r, b.lf_name, b.lfn_id, b.lfn_name, b.lfn_type_c, b.lfn_type_d, b.lfn_dir_co, b.lfn_dir_de, b.lfn_desc, b.oe_flag_l, b.oe_flag_r, b.fcode_desc, b.fcode, b.fnode, b.tnode, b.metrd_num, b.lo_num_l, b.lo_n_suf_l, b.hi_num_l, b.hi_n_suf_l, b.lo_num_r, b.lo_n_suf_r, b.hi_num_r, b.hi_n_suf_r, b.juris_code, b.dir_code, b.dir_code_d, b.cp_type, b.length, b.the_geom"
"  Join Filter: _st_intersects(b.the_geom, z.the_geom)"
"  ->  Seq Scan on public."roads" b  (cost=0.00..306.72 rows=5472 width=918)"
"        Output: b.gid, b.geo_id, b.address_l, b.address_r, b.lf_name, b.lfn_id, b.lfn_name, b.lfn_type_c, b.lfn_type_d, b.lfn_dir_co, b.lfn_dir_de, b.lfn_desc, b.oe_flag_l, b.oe_flag_r, b.fcode_desc, b.fcode, b.fnode, b.tnode, b.metrd_num, b.lo_num_l, b.lo_n_suf_l, b.hi_num_l, b.hi_n_suf_l, b.lo_num_r, b.lo_n_suf_r, b.hi_num_r, b.hi_n_suf_r, b.juris_code, b.dir_code, b.dir_code_d, b.cp_type, b.length, b.the_geom"
"  ->  Index Scan using "buffer1KM_index_the_geom" on public."buffer1KM" z  (cost=0.00..3.41 rows=1 width=48446)"
"        Output: z.gid, z.objectid, z.facilityid, z.name, z.frombreak, z.tobreak, z.postal_cod, z.pc_area, z.ct_id, z.da_id, z.taz_id, z.edge_poly, z.cchs_0708, z.tts_06, z.the_geom"
"        Index Cond: (b.the_geom && z.the_geom)"

Esta operación sólo condenada a ejecutar durante varios días? Actualmente estoy ejecutando esto en PostGIS para Windows, pero yo en teoría, podría arrojar algo más de hardware en el problema poniendo en Amazon EC2. Sin embargo, veo que la consulta es sólo el uso de un núcleo en un tiempo (hay una forma de hacer el uso más?).

Muchas gracias por toda la ayuda que le puede ofrecer!

Answer 1

Peter,

¿Qué versión de PostGIS, GEOS y PostgreSQL está utilizando?
hacer un

SELECT postgis_full_version(), version();

Se han hecho muchas mejoras entre 1.4 y 1.5 y GEOS 3.2+ para este tipo de cosas.

Además, ¿cuántos vértices tienen tus polígonos?

Haz un

SELECT Max(ST_NPoints(the_geom)) As maxp FROM sometable;

Para tener una idea de su peor escenario. Este tipo de velocidad suele estar causada por geometrías demasiado granuladas. En ese caso, es posible que quieras simplificar primero.

¿También has hecho optimizaciones en tu archivo postgresql.conf?

Answer 2

Respuesta útil de intercambio de pilas: https://stackoverflow.com/questions/1162206/why-is-postgresql-so-slow-on-windows

Ajuste de Postgres: http://wiki.postgresql.org/wiki/Performance_Optimization

desde la experiencia recomiendan ANALIZAR EL VACÍO

Answer 3

Plugin desvergonzado :) Puede ser útil leer el capítulo 8 y el capítulo 9 de nuestro libro. Acaban de salir de la imprenta. Cubrimos muchas de estas preguntas en esos capítulos.

http://www.postgis.us/chapter_08

http://www.postgis.us/chapter_09

Answer 4

Consulte los dos consejos para optimizar la consulta espacial. A mí me funcionan muy bien. http://kb.zillionics.com/optimize-spatial-query/