[postgis-devel] WKTRaster Scale and Skew

[David Zwarg]

On Fri, Sep 10, 2010 at 11:16 AM, Pierre Racine <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
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20100910/f63c089a/attachment.html>