Ich versuche, einen Schnittpunkt zwischen zwei Ebenen durchzuführen:
- Polylinienebene, die einige Straßen darstellt (~ 5500 Zeilen)
- Polygonschicht, die unregelmäßig geformte Puffer um verschiedene Punkte von Interesse darstellt (~ 47.000 Zeilen)
Letztendlich versuche ich, die Polylinien an diesen vielen (manchmal überlappenden) Puffern zu befestigen und dann die Gesamtlänge der in jedem Puffer enthaltenen Fahrbahn zusammenzufassen.
Das Problem ist, dass die Dinge langsam laufen. Ich bin mir nicht sicher, wie lange dies dauern soll, aber ich habe meine Anfrage erst nach> 34 Stunden abgebrochen. Ich hoffe, dass jemand entweder darauf hinweisen kann, wo ich einen Fehler bei meiner SQL-Abfrage gemacht habe, oder mich auf einen besseren Weg hinweisen kann, dies zu tun.
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;Ich habe einen GiST-Index für die ursprüngliche Straßentabelle erstellt und (um sicher zu gehen?) Vor der zweiten Tabellenerstellung einen Index erstellt.
Der Abfrageplan von PGAdmin III sieht folgendermaßen aus, obwohl ich leider nicht viel Geschick darin habe, ihn zu interpretieren:
"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)"Ist diese Operation nur dazu verdammt, mehrere Tage zu laufen? Ich führe dies derzeit unter PostGIS für Windows aus, aber ich könnte theoretisch mehr Hardware auf das Problem werfen, indem ich es auf Amazon EC2 stelle. Ich sehe jedoch, dass die Abfrage jeweils nur einen Kern verwendet (gibt es eine Möglichkeit, mehr davon zu verwenden?).