[postgis-devel] [PostGIS] #1114: [raster] ST_Resample
PostGIS
trac at osgeo.org
Sat Jul 9 04:31:50 PDT 2011
#1114: [raster] ST_Resample
----------------------------+-----------------------------------------------
Reporter: dustymugs | Owner: dustymugs
Type: task | Status: new
Priority: medium | Milestone: PostGIS Raster Future
Component: postgis raster | Version: trunk
Keywords: |
----------------------------+-----------------------------------------------
Comment(by pracine):
Replying to [comment:10 dustymugs]:
> I agree that the upper example can be detrimental to your raster. I'll
tweak the code to behave like the lower example, which would preserve the
raster data. If I'm incorrect about this, could you post a visual aid?
I don't think so. That would unwisely change the shape of the raster
footprint. I knew I described this better. It is in the ST_AsRaster()
specs where I describe how to align the desired raster. I will try to
describe it better here...
In the ST_Resample specs, the second series of variant to not define what
should be the new upperleft corner of the raster. They define a grid on
which the raster should snap to. So it is neither of your drawings... An
alignment grid is defined by x, y and a pixelsize. The pixel size can be
defined with just 'pixelsize', meaning that scalex = scaley and skewx =
skewy = 0 of with some of those pixelsize parameters (variants 7 and 9).
This is why I did not call them ulx and uly but just x and y. Those x and
y are arbitrary upperleft corner of ANY pixel of the new grid to snap to.
You have to compute the new ulx and uly of the resampled raster
according/to snap to this grid.
Sorry if this was not explained...
--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1114#comment:12>
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.
More information about the postgis-devel
mailing list