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

 Replying to [comment:43 dustymugs]:
 > Replying to [comment:42 mloskot]:
 > > I apologies if I've touched you or anyone.
 > >
 >
 > I have a thick skin.  I always tell people to stop with trying to use
 "with all respect", (...)
 > I plan to or hold my tongue if whatever I have to say could be REALLY
 offensive.

 I criticise ideas, not people. So, make it clear, I use such phrases to
 indicate respect to people which I always have.

 > > IMHO, the fact that there is no constraint attached does not make the
 flag useless or invalid concept.
 > >
 >
 > 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.
 2. I assume lack of constraint is documented and user is warned about what
 happens when new tiles are added.
 3. There can be a function user can execute explicitly to validate table
 and answer if regular blocking still holds
 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.

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

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

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