[postgis-devel] WKTRaster Scale and Skew

Wed Sep 22 07:11:59 PDT 2010

David,

I like that very much! It's not because the ESRI definition of World File have been confusing for years that we must continue in the same way (like GDAL did). scalex is not pixelsize. Period. I like that we name things by their real names, in a clearer way. The fact that ST_PixelSizeX will return the samething as ST_ScaleX for all non rotated rasters make the transition easy.

I think we should split ST_Rotation into ST_RotationX and ST_RotationY so a user can always test if ST_RotationX = ST_RotationY and determine himself if it is a true rotation.

+1

Pierre

From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of David Zwarg
Sent: 22 septembre 2010 09:55
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] WKTRaster Scale and Skew

Raster devs, sorry for the delay,

I've been thinking of a solution that would be acceptable moving forward for all cases.  I am playing a bit of the Devil's advocate on this issue, so please bear with me.

I'll back off on my earlier request to rename things -- I was proposing that because it made sense to me, but I see that GDAL (and the like) don't do things that way, and it would be confusing to new users.

It seems like it would be most clear to have a set of functions for accessing the georeference components, named 'scale', 'skew', and 'upperleft'. The 'scale' functions would be renamed from their current name, which is 'pixelsize'. That would provide 3 sets of functions:

Scale (renamed from Pixelsize):

 *   ST_SetScale(r,x,y)
 *   ST_ScaleX(r)
 *   ST_ScaleY(r)
Skew:

 *   ST_SetSkew(r,x,y)
 *   ST_SkewX(r)
 *   ST_SkewY(r)
Upper Left:

 *   ST_SetUpperLeft(r,x,y)
 *   ST_UpperLeftX(r)
 *   ST_UpperLeftY(r)
Then, I propose adding some new functions that compute their values based on the values in the georeference. I propose that pixelsize is now computed from scale and skew, to accurately reflect the size of a pixel at any rotation angle.  Also, rotation is also computed from scale and skew.  When these values are 'set', both scale and skew will change. That would provide another couple sets of functions:

PixelSize (dynamically computed from scale and skew):

 *   ST_SetPixelSize(r,x,y)
 *   ST_PixelSizeX(r)
 *   ST_PixelSizeY(r)
Rotation (dynamically computed from scale and skew):

 *   ST_SetRotation(r,angle)
 *   ST_Rotation(r)
If one uses these methods on a North-up raster, skew will be 0,0, rotation will be 0, and PixelSize = Scale (let's say these are 1).  This is consistent with the way wktraster currently works. Now, when one uses these methods on a Pi/6 radian (30 degree) rotated raster, the skew will be 0.5, 0.5, rotation will be Pi/6, PixelSize will still be 1, and scale will be 0.866, 0.866.  It is important that as one rotates the raster, the Pixelsize remains constant. Note that the skew values are pixelsize * sin(rotation), and scale values are pixelsize * cos(rotation).

I haven't yet figured out a good way to represent rotation for diamond-shaped rasters (with different skewX and skewY values).  Maybe ST_Rotation is broken into ST_RotationX and ST_RotationY?

Thoughts?
Zwarg
On Tue, Sep 14, 2010 at 11:19 AM, Pierre Racine <Pierre.Racine at sbf.ulaval.ca<mailto:Pierre.Racine at sbf.ulaval.ca>> wrote:
So in the end, what are the proposed changes from the users point of view (in rtpostgis.sql)? Sorry I have been away a bit.

Pierre

From: postgis-devel-bounces at postgis.refractions.net<mailto:postgis-devel-bounces at postgis.refractions.net> [mailto:postgis-devel-bounces at postgis.refractions.net<mailto:postgis-devel-bounces at postgis.refractions.net>] On Behalf Of David Zwarg
Sent: 10 septembre 2010 11:35
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] WKTRaster Scale and Skew

On Fri, Sep 10, 2010 at 11:16 AM, Pierre Racine <Pierre.Racine at sbf.ulaval.ca<mailto:Pierre.Racine at sbf.ulaval.ca>> wrote:
>  Width is computed based on scale & skew?
In 99% of the cases there is no rotation and pixel width & height ARE synonyms for scale X and scale Y. Is it worth changing their names? Adding confusion? How does GDAL name it?

I agree that 99% of the time, there is no rotation.  I don't propose changing the names of the pixel width methods, just change the way it is computed to account for the skewing.  I wouldn't mind hiding the set_skews() method, in favor of accepting all adjustments in the form of the georeference string.  This is the way GDAL gets around it -- they don't name the 6 components of the georeference, and just note that "In case of north up images, the GT(2) and GT(4) coefficients are zero" -- not much help if you want to know what happens when north is not up.

>We don't call it scaleX and scaleY, but cell_width_x and cell_height_y
>We don't call it skewX and skewY, but cell_width_y and cell_height_x
In rt_api.c? Why not...

>We separate the accessors for the pixel width and the georeference component that is now used as the width.
You mean creating a "truepixelwidth" function? Same reluctance since it is not really a width when the pixel shape is a diamond. But you could say "this happen only 0.001 of the time"... Does that mean removing or renaming the ST_PixelSizeX and ST_PixelSizeY function?

I would propose some other name besides pixel 'width', since it's only a part of the width.  Maybe we don't have any accessors for this value at all, and the only way to get it is through the georeference string?

>Tests assume the upper left coordinate is SMALLER in the X and GREATER in the Y for all other coordinates in the raster -- this would require adjusting our tests to handle the coordinate space uniformly.
Ok.

My main concern is to not confuse users with scale, skew and width. Most people know only pixelsize.

I agree -- it took me a few minutes to understand that the parameters are not exactly width or scale or skew.  This may be sacrilege, but what if all that was hidden under the hood, and we just provide the true width/height get functions and the get/set functions for the georeference?  Because most of the time, nobody will care about the skew.

Thoughts?
Zwarg

Pierre
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net<mailto:postgis-devel at postgis.refractions.net>
http://postgis.refractions.net/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net<mailto:postgis-devel at postgis.refractions.net>
http://postgis.refractions.net/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20100922/e5c8820e/attachment.html>