[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 dustymugs):

 Replying to [comment:13 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()?
 >

 Yes.  AddRasterColumn adds a new empty raster column and constraints to an
 existing table while populate_raster_column() only adds appropriate
 constraints to an existing and populated raster column.

 > > 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()?)
 >

 Sounds like a plan to me.  The loader won't use apply_raster_constraints
 (sounds more appropriate for the actions to be done) as that requires
 another pass over the able while the loader has already looked at the
 data.  So the loader will set constraints as long as the import type isn't
 append.

 > > 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?
 >

 Both rasters have the a band of same index of type PT_8BUI.  All data in
 raster 1 band 1 has values between 0 - 125.  All data in raster 2 band 1
 has values between 126 - 255.  And both bands have nodata pixels.  So,
 raster 1 band 1 would need a nodata value greater than 125 while raster 2
 band 1 would need a nodata value less than 126.  Hence, same pixeltype for
 both bands at same index but 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...

 Yes.  There's no way around this limitation.

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