Have you thought of using rasters ? Sitansu @ kCube
On Sun, Jun 30, 2013 at 10:33 PM, Martin Davis <[email protected]> wrote: > Hi, Karsten. > > One potential problem with merging all the buffers for a given value is > that you may wind up with a very large polygon that creates its own > handling issues. > > If you only need this for analytical purposes, not for display, then it > might work better to aim for a middle ground. You could merge the buffers > in "clumps". To do this, you need to partition the buffers into > spatially-coherent groups. A simple way to do this is to create a grid > over the area (say based on the coordinate system you are using). Create a > reprsentative point for each buffer (e.g. the interior point or centroid). > The buffers can then be assigned to the grid cell their point lies in. > Then group the buffers by their grid cell, and union each group. > > Actually, if you want to carry on and create single polygons, then the > clumped buffer polygons give a better basis to work from (since they should > have many fewer points than the source polygons). > > If there are still memory issues with the clumped unions, then you can > carry out this process in an iterated fashion, starting with small grid > cells and then repeating with a larger size. (At this point you will have > basically reimplemented the GEOS CascadedUnion algorithm. But that's ok - > performing the algorithm at the SQL level allows more control over memory > and processing usage). > > I'd be interesting to hear if this approach works out. > > Martin > > > On 6/28/2013 5:11 PM, karsten vennemann wrote: > > I was wondering if there is a good (or best practice) approach on how to > merge geometry features that are touching or overlapping and have one > common value in one table field.**** > > ** ** > > Here is what I was trying to do: given a large dataset such as the > (detailed NHD data layer) of rivers in California I created multiple > buffers and inserted the results into a new table with one geometry column > adding a score value to each of the same buffers distances used. Thus the > buffer polygon layer has a score with a value of 10,100,500 and 1000 m > corresponding to the buffer distance used. Given the approach I used to > create the buffers those are often spatially overlapping (because there was > no merge operation of the buffers and because the rivers are split along > the flow line in multiple segments by node in the source shape file). The > resulting layer works ok for my purposes (which is to retrieve information > in which buffers a certain location is intersecting it with the river > buffer (results can be 10,100,500 and 1000 or no intersect with the > buffers).**** > > Now the layers is about 20 GB big disk size having a lot of unnecessary > geometries with are overlapping.**** > > How can I go about merging all the existing geometries on this huge data > set into a result layer that has (optimally ) only 4 polygons with the > result scores to find my intersects. **** > > When I tried some of my own approaches (e.g. using st_collect and such to > do this) so far whenever I started these sever resource intensive > operations soon these where aborted by the system because i got some kind > of out of memeonry errosr on my server (an ubuntu achjien). Is there a good > way to optimize this kind of query operation without using 100% of my > server ram so that I will not run out of memory or resulting in a lengthy > query that would be running for 6 weeks or so J ?**** > > Any query examples or general insight are greatly appreciated .**** > > ** ** > > Cheers**** > > Karsten**** > > ** ** > > Karsten Vennemann**** > > **** > > Terra GIS Ltd**** > > 2119 Boyer Ave E**** > > Seattle, WA 98112**** > > USA**** > > tel ++ 206 905 1711**** > > fax ++ 925 905 1711**** > > ** ** > > > _______________________________________________ > postgis-users mailing > [email protected]http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users > > > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.2904 / Virus Database: 3184/6359 - Release Date: 05/26/13 > Internal Virus Database is out of date. > > > > _______________________________________________ > postgis-users mailing list > [email protected] > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users > >
_______________________________________________ postgis-users mailing list [email protected] http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
