[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:42 mloskot]:
 > Replying to [comment:39 dustymugs]:
 > > Replying to [comment:37 mloskot]:
 > > > Please, with all my respect, don't be scientific-ignorant here guys
 and don't make PostGIS Raster just another GRASS, please.
 > >
 > > scientific-ignorant?  You'll have to elaborate on that.
 >
 > I have a constant impression that the PostGIS Raster is becoming more
 fully-featured analytical GIS system where storage use cases are
 forgotten.

 Now that make sense.  Yes, I agree with that as my needs are a mix of
 analytical and storage/management.  What I consider the biggest problem
 with PostGIS Raster at the moment is the enormous number of items that
 people want done in the project (particularly the imminent feature freeze
 for PostGIS 2.0) versus the limited amount of time for new development and
 maintenance.

 > 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", "with no disrespect", "no offense" or any variant as
 they're almost always the opposite.  Be honest and speak your mind.  I
 plan to or hold my tongue if whatever I have to say could be REALLY
 offensive.

 > > > If you decide to get rid of this flag, then the only way to
 determine if a table is tiles storage or not is to perform slow (!) query.
 > > >
 > >
 > > From the looks of it in the AddRasterColumn function, regular_blocking
 is just a boolean value passed with no true validation of making sure
 > > that no tiles overlap and there are no gaps.  As the appropriate
 constraints won't be added until after PostGIS 2.0 is released, we could
 just
 > > add a garbage constraint to indicate that a column is regularly
 blocked.
 >
 > AFAIR, constraint on regular blocking has never been planned. It would
 be slow anyway.
 > The uploader is supposed to play the key role here and take care of
 assuring tiles in a table are regularly
 > blocked if such configuration is requested.
 > 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?  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.

 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.

 2. something to test that a table has no gaps.

 For #1, we can do a table EXCLUDE constraint to make sure that no rasters
 overlap.

 As for #2, that'll require some thinking.

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