[postgis-devel] [PostGIS] #2024: raster: ST_Union is buggy

PostGIS trac at osgeo.org
Fri Oct 5 11:15:00 PDT 2012

#2024: raster: ST_Union is buggy
  Reporter:  robe     |       Owner:  dustymugs    
      Type:  defect   |      Status:  closed       
  Priority:  blocker  |   Milestone:  PostGIS 2.1.0
 Component:  raster   |     Version:  trunk        
Resolution:  fixed    |    Keywords:               

Comment(by pracine):

 > pracine:

 > I also see it as the most common use case.  Why would I want to just
 union tiles and be relegated to the size of my tiles that happen to have
 my area of interest. In fact if you were going to fix an extent -- I would
 suggest you allow the user to pass the extent in as an argument to Union
 allowing the union to create the size and throw out anything that doesn't
 fit.  That would save having to compute in most cases and probably satisfy
 a lot of user needs.

 Good idea. Clip and union in the same step...

 > I see the common case -- as doing small analysis of a region say a
 500x500 area and clipping to that region, which is what the browser would
 expect.  The browser only wants to see the region that was asked for. But
 my perspective might be different since I'm coming from a web-developer
 POV where I see the user specifying the area and I give them just that
 region that fits the area they requested.  The unioning tons and tons of
 huge tiles seems useful if you are outputting large coverages as a single
 file, which quite frankly puts me to sleep.

 I agree with you but I'm wondering what is the biggest extent we can still
 union in reasonable time. If I remember well, with 2.0.1 unioning one srtm
 tile was taking ages.

Ticket URL: <https://trac.osgeo.org/postgis/ticket/2024#comment:27>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.

More information about the postgis-devel mailing list