[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: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 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.

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