[postgis-devel] [PostGIS] #1267: [raster] Add manual height/weight support to ST_Resample

[PostGIS]

#1267: [raster] Add manual height/weight support to ST_Resample
----------------------------+-----------------------------------------------
 Reporter:  serveralex      |       Owner:  dustymugs            
     Type:  enhancement     |      Status:  assigned             
 Priority:  medium          |   Milestone:  PostGIS Raster Future
Component:  postgis raster  |     Version:  trunk                
 Keywords:                  |  
----------------------------+-----------------------------------------------

Comment(by bnordgren):

 Replying to [comment:6 pracine]:
 > Replying to [comment:5 bnordgren]:
 > > I agree. The unit of borrowing should be the entire grid definition
 (width, height, and the affine transform to the geopoint). Note that this
 also requires that the target raster "borrow" the SRID, as the affine
 transform is tied to a particular geospatial CRS.
 >
 > I don't see the point of providing the width and the height at the same
 time as the affine transform... You are then stretching the raster to the
 footprint of the other one which is not a resampling operation but more
 like a wrapping operation. We decided (long ago) that wrapping would be a
 different function (ST_Wrap) yet to be designed...

 ???!!!?? You lost me.

 "Stretching" is performed only by the affine transform, not by the
 width/height values.

 "Wrapping", I can't find anywhere on the trac site except for #454, which
 does not appear to be what you're talking about.

 As to "the point" of providing width/height values at the same time as the
 affine transform: you're already requiring that the user ''provide'' width
 and height, as these are mandatory parameters of the raster type; you're
 just ignoring the values they provide in favor of other values which are
 computed by some unspecified means over which the user has no control.
 This caused user confusion that their provided values were ignored, hence
 this ticket. "The point" of respecting these values would be to produce
 the result requested by the user.

 To put it another way, if the user specifically asked for a particular
 result, there should be a very good reason to give them something
 different. Is there a good reason?

 > Again the same argument about on-the-fly reprojection... We should not
 reproject on the fly to a new SRID before PostGIS do it itself.
 ST_Resample(raster, ref_raster) should fail with a warning if both SRID
 are different.

 I was not making a statement about whether we should project on the fly or
 not. The affine transform is already tied to a particular SRID. If you
 blindly apply the transform without paying attention to which SRID it
 applies to, you'll successfully return when you should have raised an
 exception. Not an argument about on-the-fly projection at all.

 > > However, I don't see why it should be necessary to alter the signature
 in order to do this. The user can construct a raster with no bands,
 configure its grid definition to their heart's content, then require that
 the resampling operation respect the grid definition specified in the
 "ref" raster. If they want to resample many sources to a common grid, they
 just keep specifying the same "ref" raster over and over again.

 > Sure but this is tedious. We provide functions variants to make the life
 of our users easy so they choose our software!

 Let me get this straight: It's not tedious to ask them to supply a
 "reference raster" where the function ignores the required "height" and
 "width" parameters, but it is tedious to ask them to supply a "reference
 raster" when those parameters are respected? ???!?!!!!!

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