Czy w PostGIS jest funkcja rozpuszczania inna niż st_union?

Szukam funkcji do rozpuszczenia wspólnych granic między elementami wielokąta w tabeli. ST_UNION () prawie robi to, czego szukam, ale tworzy wielobok ze wszystkich wielokątów w warstwie, niezależnie od tego, czy mają one wspólną granicę, czy nie. Wolałbym jedynie rozpuszczać granice między wielokątami, które się stykają. Pomyślałem, że powinien istnieć sposób użycia ST_TOUCHES (), ale wtedy potrzeba funkcji rozpuszczania wydaje się tak powszechna, że ​​byłbym zaskoczony, gdyby nie było wbudowanej funkcji, aby to osiągnąć.

Przypadek użycia wygląda następująco: Pobrałem dane Corine Landcover dla dużego kraju europejskiego i chcę zlikwidować granice między różnymi typami lasów (około 75 000 wielokątów w jednej tabeli). Próbowałem ST_UNION, ale nie udało mi się z błędem „brak pamięci” (chociaż 30 000 wielokątów działało):

create table corine00 as 
  select st_union(the_geom) as the_geom, 
         sum(area_ha) as area_ha,
         substr(code_00,1,2) as code_00
  from clc00_c31_forests
  group by substr(code_00,1,2)

Uwaga: wszystkie kody lasów zaczynają się od „31”, a ja korzystam z PostGIS 1.4, wersja GEOS: 3.2.0-CAPI-1.6.0

ST_MemUnion () uruchomi naiwny i wolny proces pamięci. Możesz spróbować, jeśli twój problem jest wystarczająco mały, może zakończyć się w rozsądnym czasie. Możesz także po prostu podzielić swój problem na połówki, a następnie uruchomić je razem. Ponieważ wypadkowe będą miały znacznie mniej punktów niż dane wejściowe, możesz w ten sposób dopasować cały problem do pamięci. Lub użyj szybkiej procedury głodnej pamięci na połówkach i wolniejszej procedury na końcowym scaleniu.

Wierzę, że ST_Dump jest tym, czego chcesz:

ST_Dump :

Zwraca zestaw wierszy geometry_dump (geom, ścieżka), które składają się na geometrię g1 .... Na przykład można go użyć do rozwinięcia MULTIPOLYGONS w POLYGONS. ...

Więc w twoim przypadku:

 SELECT (ST_Dump( ST_Union( the_geom ) )).geom
 FROM clc00_c31_forests
 GROUP BY substr(code_00,1,2)

Nie jestem pewien, jak to będzie współdziałać z tworzeniem tabeli, którą próbujesz wykonać, ale powinno dać ci geometrie jako osobne wpisy. Będziesz wtedy w stanie wykonać połączenie przestrzenne (używając && i ST_Contains) między dwiema tabelami, aby zebrać dane do geometrii.

Czy Twój PostGIS jest skompilowany z GEOS 3.1.0+? W tej wersji zaimplementowano znacznie szybsze połączenie kaskadowe , ale jeśli nie zostanie znalezione, użyje starszego kodu, który jest o rząd wielkości wolniejszy.

Aktualizacja : wygląda na to, że Twój PostGIS korzysta z kaskadowego związku, ale głód pamięci jest prawdziwy. Spróbuję zwiększyć dostępną pamięć do twojej instancji Postgres, oto kilka porad z dyskusji Paula Ramseya na temat FOSS4G PostGIS z 2007 roku :

• Dostęp do dysku jest wolny, więc można uzyskać wyższą wydajność poprzez użycie większej ilości pamięci do buforowania danych!
  • Zwiększać shared_buffers
  • Fizyczna pamięć RAM - system operacyjny potrzebuje * 75%
• Sortowanie jest szybsze w pamięci
  • Zwiększać work_mem
• Czyszczenie dysku jest szybsze z większą ilością pamięci
  • Zwiększać maintenance_work_mem
• Przydzielone na połączenie
• Również
  • Zwiększać wal_buffers
  • Zwiększać checkpoint_segments
  • Zmniejszać random_page_cost

W twoim przypadku spróbuję zwiększyć shared_buffers, ogólne zalecenie to 25% dostępnej pamięci dla serwera bazy danych, ale spróbuj zwiększyć ją do 3-4x bieżącej wartości i sprawdź, czy się skończy.