<div dir="ltr">Have you thought of using rasters ? <div>Sitansu</div><div style>@ kCube </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 30, 2013 at 10:33 PM, Martin Davis <span dir="ltr"><<a href="mailto:mtnclimb@telus.net" target="_blank">mtnclimb@telus.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hi, Karsten.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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).<br>
    <br>
    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).<br>
    <br>
    I'd be interesting to hear if this approach works out.  <br>
    <br>
    Martin<div><div class="h5"><br>
    <br>
    <div>On 6/28/2013 5:11 PM, karsten vennemann
      wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      
      
      
      <div>
        <p class="MsoNormal"><font face="Arial"><span style="font-size:10.0pt;font-family:Arial">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.<u></u><u></u></span></font></p>
        <p class="MsoNormal"><font face="Arial"><span style="font-size:10.0pt;font-family:Arial"><u></u> <u></u></span></font></p>
        <p class="MsoNormal"><font face="Arial"><span style="font-size:10.0pt;font-family:Arial">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).<u></u><u></u></span></font></p>
        <p class="MsoNormal"><font face="Arial"><span style="font-size:10.0pt;font-family:Arial">Now the layers is about 20 GB big disk
              size having a lot of unnecessary
              geometries with are overlapping.<u></u><u></u></span></font></p>
        <p class="MsoNormal"><font face="Arial"><span style="font-size:10.0pt;font-family:Arial">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. <u></u><u></u></span></font></p>
        <p class="MsoNormal"><font face="Arial"><span style="font-size:10.0pt;font-family:Arial">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 </span></font><font face="Wingdings"><span style="font-size:10.0pt;font-family:Wingdings">J</span></font><font face="Arial"><span style="font-size:10.0pt;font-family:Arial"> ?<u></u><u></u></span></font></p>

        <p class="MsoNormal"><font face="Arial"><span style="font-size:10.0pt;font-family:Arial">Any query examples or general  insight
              are  greatly
              appreciated .<u></u><u></u></span></font></p>
        <p class="MsoNormal"><font face="Arial"><span style="font-size:10.0pt;font-family:Arial"><u></u> <u></u></span></font></p>
        <p class="MsoNormal"><font face="Arial"><span style="font-size:10.0pt;font-family:Arial">Cheers<u></u><u></u></span></font></p>
        <p class="MsoNormal"><font face="Arial"><span style="font-size:10.0pt;font-family:Arial">Karsten<u></u><u></u></span></font></p>
        <p class="MsoNormal"><font color="navy" face="Verdana" size="3"><span style="font-size:12.0pt;font-family:Verdana;color:navy" lang="DE"><u></u> <u></u></span></font></p>
        <p class="MsoNormal"><font color="navy" face="Verdana" size="3"><span style="font-size:12.0pt;font-family:Verdana;color:navy" lang="DE">Karsten Vennemann</span></font><span lang="DE"><u></u><u></u></span></p>
        <p class="MsoNormal"><font face="Times New Roman" size="3"><span style="font-size:12.0pt" lang="DE"> <u></u><u></u></span></font></p>
        <p class="MsoNormal"><font color="navy" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana;color:navy" lang="DE">Terra GIS Ltd</span></font><span lang="DE"><u></u><u></u></span></p>
        <p class="MsoNormal"><font color="navy" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana;color:navy" lang="DE">2119 Boyer Ave E</span></font><span lang="DE"><u></u><u></u></span></p>
        <p class="MsoNormal"><font color="navy" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana;color:navy">Seattle, WA 98112</span></font><u></u><u></u></p>
        <p class="MsoNormal"><font color="navy" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana;color:navy">USA</span></font><u></u><u></u></p>
        <p class="MsoNormal"><font color="navy" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana;color:navy">tel ++ <a href="tel:206%20905%201711" value="+12069051711" target="_blank">206 905 1711</a></span></font><u></u><u></u></p>

        <p class="MsoNormal"><font color="navy" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana;color:navy">fax ++ <a href="tel:925%20905%201711" value="+19259051711" target="_blank">925 905 1711</a></span></font><u></u><u></u></p>

        <p class="MsoNormal"><font face="Times New Roman" size="3"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
postgis-users mailing list
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a>
</pre>
      <br>
      <fieldset></fieldset>
      <br>
      <p color="#000000" align="left">No virus
        found in this message.<br>
        Checked by AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a><br>
        Version: 2013.0.2904 / Virus Database: 3184/6359 - Release Date:
        05/26/13<br>
        Internal Virus Database is out of date.</p>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br>
<br></blockquote></div><br></div>