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 list
[email protected]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
No virus found in this message.
Checked by AVG - www.avg.com <http://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
