[postgis-devel] [PostGIS] #1319: [raster] Make raster_columns a view and AddRasterColumn enforce more

[PostGIS]

#1319: [raster] Make raster_columns a view and AddRasterColumn enforce more
----------------------------+-----------------------------------------------
 Reporter:  robe            |       Owner:  robe         
     Type:  task            |      Status:  new          
 Priority:  high            |   Milestone:  PostGIS 2.0.0
Component:  postgis raster  |     Version:  trunk        
 Keywords:                  |  
----------------------------+-----------------------------------------------

Comment(by pracine):

 Replying to [comment:11 dustymugs]:
 > The importer will call an update AddRasterColumn which only needs to
 work on the table having the raster column added.

 I guess this is useless if we 'CREATE TABLE foo AS', right? This is why we
 also need an equivalent of populate_raster_columns()?

 > I'm planning on having the importer run by default in a strict mode
 (where all rasters passed in when the importer is called have the same
 scale x/y, srid and band types.  There will be a set of flags to disable
 specific constraints though.

 Why not automatically maintaining a set of 'samescalex', 'samescaley',
 'samesrid' and 'samebandtype' flags as it loads many rasters so you can
 determine at the end which constraint you can set. Actually this is
 exactly what populate_raster_columns() would do... Again it is not wise to
 do outside the database (like creating the overviews) what is useful to be
 done inside (updating the constraints). I think AddRasterColumn() become
 obsolete with 2.0 and should be replaced with the equivalent of
 Populate_Raster_Columns() (or Apply_Raster_Constraints()?)

 > I don't know how useful nodatavalue is because there could be different
 nodatavalues between two rasters' bands of the same index because the
 values might be in different ranges.  Say raster 1 band 1 has values
 between 0 - 125 while raster 2 band 1 has values between 126 - 255.
 Though the two rasters are aligned, they have different nodata values.

 I don't follow you. Why would two raster storing a different range of
 values would have different nodata values?

 > Though extent might be valuable as it would be done using...
 >
 > {{{
 > SELECT ST_ConvexHull(ST_Collect(tile)) FROM tmax_2010
 > }}}
 >
 > It isn't fast though.  On my tmax_2010 table with 36712 rows with tile
 size of 100x100, it takes 1 second.  So for every year between 1965 to
 2011, the view would take 47 seconds (assuming 1 second for each table).
 Add my tmin and precip datasets for the same years, we're talking 141
 seconds.

 So we will tell people to query the specific table with
 ST_Extent(rast::geometry) to get the extent...

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1319#comment:13>
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.