Jak przyspieszyć partycjonowanie przestrzeni w Postgis?

Mam kilka nakładających się wielokątów i próbuję podzielić przestrzeń, aby uniknąć nakładania się tych wielokątów. Myślę, że mój problem jest dość prosty. Używając jakiegoś produktu ESRI i http://arcscripts.esri.com/details.asp?dbid=16700 mój współpracownik obliczył go w 48s.

Próbuję to zrobić za pomocą Postgis przy użyciu http://s3.opengeo.org/postgis-power.pdf#page=24 (zgadując szczegóły, używając http://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology jako inspiracja), ale jest tak wolny, że nie mogę tego zrobić z więcej niż 10 polami (mam ich 800 do podzielenia). Powolna część to ST_Union, próbowałem różnych rzeczy, ale żadne nie zakończyło się sukcesem, oto obecny stan rzeczy:

select geom from
(select st_linemerge(st_union(geom)) as geom from
    (select st_exteriorring((st_dumprings((st_dump(t.geom)).geom)).geom) as geom from
        (SELECT geometry AS geom, id
               FROM tt
              WHERE campaign_id = 204
              ORDER BY id limit 200) t) t2) t3

trwało to 26 minut (linemerge () tak naprawdę nie jest). Polys to MultiPolygons na wypadek, gdyby st_dump Cię zepsuł.

Czy masz jakieś wskazówki? St_union () linii jest bardzo wolną częścią.

Dzięki,

Nico

PS: oto kilka liczb: 852 wielokąty, prowadzące do 14880 wielokątów, prowadzące do 21467 linii łącznych o łącznej długości 315513 wierzchołków.

postgis topology optimization

— nraynaud
źródło

Jeśli nikt nie odpowie, możesz spróbować listy mailingowej postGIS.

— GIS-Jonathan

Naprawdę nie jestem fanem list mailingowych, zresztą może to być również problem GEOS, który może narzekać na JTS, cóż, wolę pozostawić problem otwarty.

— nraynaud

zbierając linie i wykonując połączenie o pustej geometrii, mogę to zrobić w 800s: st_union (st_collect (geom), st_setsrid (geomfromtext ('POINT EMPTY'), 900913)), który jest prawie 20 razy wolniejszy niż ESRI.

— nraynaud

z pamięci, spróbuj upuścić st_union z st_linemerge (st_union ...), jeśli to pomaga

— simplexio

Odpowiedzi:

Ta odpowiedź może nie pomóc bezpośrednio @nraynaud, ale mam nadzieję, że rzuci nieco światła na ten temat.

Podobny problem występuje w spatiaLite <4.0 z powodu problemu z GEOS. Zobacz ten link, aby omówić problem.

Obejściem tego problemu jest zastąpienie funkcji ST_Union () funkcją ST_UnaryUnion (ST_Collect ()). Niestety ST_UnaryUnion jest dostępny dopiero po GIS 2.0 (o ile wiem).

— Scro
źródło

Z jakiej wersji PostGIS korzystasz? Łączenie jest znacznie wolniejsze, jeśli korzystasz z PostGIS <1.4 lub GEOS <3.2. Znacznie szybsze połączenie zostało wprowadzone w 1.4, ale wymaga również GEOS 3.2+. Więc najpierw, jeśli używasz mniejszej niż 1.4, zaktualizuję do co najmniej 1.5.

SELECT postgis_full_version();

Sprawdzić.

Masz również zamiar zachować oryginalne krawędzie wielokątów. Jeśli chcesz tylko usunąć nakładające się obszary,

SELECT ST_Union(geom) FROM tt WHERE campaign_id = 204;

Zrobiłby lewę.

— LR1234567
źródło

cześć, oto wynik: „POSTGIS =” 1.5.3 ”GEOS =„ 3.3.2-CAPI-1.7.2 ”PROJ =„ Rel. 4.8.0, 6 marca 2012 r. „LIBXML =” 2.7.3 „USE_STATS”. Nie mogłem ostatnio znaleźć żadnego istotnego dodatku do związku w GEOS. Znalazłem jedno przyspieszenie w związkach wielokątów, ale nie łączę wielokątów i to przyspieszenie wydaje się kontrowersyjne. Absolutnie nie chcę łączyć moich wielokątów, ponieważ muszę dodawać wartości dla nakładających się wielokątów.

— nraynaud