[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:15 pracine]:
 > Replying to [comment:14 dustymugs]:
 > > Replying to [comment:13 pracine]:
 > > > Replying to [comment:11 dustymugs]:
 >
 > > > 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.
 >
 > apply_raster_constraints() can be called on a single table so this extra
 pass should take about 1 second right? Not a big deal. The advantage of
 getting the job done by apply_raster_constraints as a post loading query
 is that we can get rid of AddRasterColumn()... and write a simpler loader
 (no metadata check, just load everything blindly and the post process will
 apply the right constraints). I'm just trying to save you work and KISS...
 >

 I think it'll take longer because it needs to check each row to see what
 the table's constraints should be.  So no way around that issue.  The only
 way that this can be fast is to blindly attempt to apply all the
 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?
 > > >
 > >
 > > 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.
 >
 > The same logic applies to pixeltypes. There is no more reason a nodata
 value should be different from one raster to the other in a consistent
 dataset composed of many rasters than there are reasons the pixeltypes
 should be different from one raster to another. Anyway the constraint is
 just not set if this happen, right? In most case it should not happen and
 some people already fetch the nodata values from raster_column.
 >

 Alright.  Works for me.  From the responses we got from raster plugin
 developers, none of them use raster_columns.  I want to know why anyone
 would be using the static raster_columns table.

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