[postgis-devel] [PostGIS] #1319: [raster] Make raster_columns a constraint-based view, replace AddRasterColumn with AddRasterConstraints and expand # of constraints on raster columns

[PostGIS]

#1319: [raster] Make raster_columns a constraint-based view, replace
AddRasterColumn with AddRasterConstraints and expand # of constraints on
raster columns
----------------------------+-----------------------------------------------
 Reporter:  robe            |       Owner:  dustymugs    
     Type:  task            |      Status:  assigned     
 Priority:  critical        |   Milestone:  PostGIS 2.0.0
Component:  postgis raster  |     Version:  trunk        
 Keywords:                  |  
----------------------------+-----------------------------------------------

Comment(by dustymugs):

 Replying to [comment:44 mloskot]:
 > Replying to [comment:43 dustymugs]:
 > > But what happens if the end user appends more rasters to that column
 flagged as regular_blocking?
 >
 >
 > 1. I assume, in regular blocking use case, it is very rare case,
 unlikely to happen.

 Appending more rasters should work if a table constraint on regular
 blocking (see below) is delayed until the end of transaction.

 > 2. I assume lack of constraint is documented and user is warned about
 what happens when new tiles are added.

 At the present, the documentation on the raster_columns and
 raster_overviews tables is far and few in-between.

 > 3. There can be a function user can execute explicitly to validate table
 and answer if regular blocking still holds

 That would be needed to validate that a column of rasters is regularly
 blocked.

 > 4. Given 1, 2 and 3, I see no problem.
 >
 > > Ideally, regular_blocking should be a constraint of some sort as if
 you want a
 > > column to be regular_blocking, you should be willing to enforce a rule
 to that effect.
 >
 > It will be expansive operation. However, Constraint is removable,
 fortunately, so performance hit can be removed as well.
 >

 Yes.  Hence why maximum extent is a constraint.  Remove it if you can't
 afford the performance hit in bulk inserts or updates.

 > > To get regular_blocking though, there are two items that need to
 happen:
 > >
 > > 1. ST_Overlaps(raster, raster) to make sure no two rasters overlap as
 isn't planned for 2.0.
 >
 > OK
 >
 > > 2. something to test that a table has no gaps.
 >
 > There is a concept I have briefly discussed with Pierre when we met last
 time in Denver which is linked tiles.
 > If there are images with repeated content (e.g. all pixels are NODATA),
 such tiles could be linked instead of storing copies.
 > This could solve gaps: if there is a gap, link NODATA tile.
 >
 > Finally, clients rendering tiles should be able to handle gaps easily.
 >

 I don't think that is a problem at the moment.  qgis with the postgis
 raster plugin seems to have no problems with gaps in a coverage.

 > > For #1, we can do a table EXCLUDE constraint to make sure that no
 rasters overlap.
 >
 > Yes.
 >
 > > As for #2, that'll require some thinking.
 >
 > Indeed.

 With additional thinking and diagramming, a table EXCLUDE constraint could
 work assuming the right function is written.

 I think a possible interim solution (at least for 2.0 code freeze) is to
 add a regular_blocking column to the raster_columns view with a garbage
 constraint that allows the end-user (who should know their own data) to
 specify that a column is regularly blocked.  A constraint is best as that
 makes no assumptions and can be done within the database but won't be
 available until 2.1.

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