J'essaie de réaliser une intersection entre deux couches:
- Couche de polyligne représentant certaines routes (~ 5500 lignes)
- Couche de polygones représentant des tampons de forme irrégulière autour de divers points d'intérêt (~ 47 000 lignes)
En fin de compte, ce que j'essaie de faire, c'est d'attacher les polylignes à ces nombreux tampons (qui se chevauchent parfois), puis de résumer la longueur totale de la chaussée contenue dans chaque tampon.
Le problème est que les choses tournent lentement. Je ne sais pas combien de temps cela devrait prendre, mais j'ai juste abandonné ma requête après> 34 heures. J'espère que quelqu'un pourra soit signaler où j'ai fait une erreur avec ma requête SQL, soit me montrer une meilleure façon de procéder.
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;J'ai un index GiST créé pour la table des routes d'origine et (juste pour être sûr?) Créer un index avant de créer la deuxième table.
Le plan de requête de PGAdmin III ressemble à ceci, bien que je crains de ne pas avoir beaucoup de compétences pour l'interpréter:
"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)"Cette opération est-elle vouée à être exécutée pendant plusieurs jours? J'exécute actuellement cela sur PostGIS pour Windows, mais je pourrais en théorie jeter plus de matériel sur le problème en le mettant sur Amazon EC2. Cependant, je vois que la requête n'utilise qu'un seul noyau à la fois (existe-t-il un moyen de le faire utiliser davantage?).