[raster] Create functions returning correct pixel size calculations

[dzwarg]

The pixel width returned is the A component of the georeference, and the pixel height returned is the E component of the georeference. When looking closer at rotation, it became apparent that these values aren't truly the pixel width & height, but the X component of width, and the Y component of height, respectively. The B and D components of the georeference are the X component of the height, and the Y component of the width, respectively.

The true pixel with is actually sqrt(A^{2 + D}2), and the true pixel height is actually sqrt(B^{2 + E}2).

Do we want another accessor that returns the component of the georeference, in addition to rt_raster_get_pixel_width, which returns the true pixel width?

[dzwarg]

Those equations should be:

true pixel width: sqrt(A² + D²) true pixel height: sqrt(B² + E²)

[pracine]

The problem is that when skewx is not equal to skewy the pixel shape becomes a diamond and the 'width' and 'height' do not necessary look like a width and a height. What should be the name of the function then? Same question for ST_Rotation since the result of the composition of skex and skewy is not necessarily a rotation. ST_SetRotation make sence though since you impose both values.

[dzwarg]

Well, skewx and skewy may be unequal for small rotations. The ratio of skewx / scaly and skewy / scalex remains constant, though.

I do know what you refer to, though — when a raster is indeed skewed, or diamond shaped, there are really 2 rotations; one for the amount off the X axis, and one for the amount off the Y axis.

Would it be acceptable if ST_Rotation returned NaN for conditions when non-uniform rotations are detected, and was documented as such?

I agree that st_setrotation doesn't have this problem, since you are setting the skew/scale for both dimensions at the same time.

[pracine]

David, So I guess the conclusion to this is that we might want a ST_PixelSize function (maybe more a set of ST_PixelSizeX and ST_PixelSizeY or even better ST_PixelWidth and ST_PixelHeight), maybe a ST_Rotation and certainly a ST_SetRotation.

There is already a ticket for ST_SetRotation (#482) but not for ST_PixelHeight, ST_PixelWidth and ST_Rotation.

We could close this one and create a ticket for them (or mention them in the specifications of future versions).

Agreed?

[dzwarg]

Replying to pracine:

David, So I guess the conclusion to this is that we might want a ST_PixelSize function (maybe more a set of ST_PixelSizeX and ST_PixelSizeY or even better ST_PixelWidth and ST_PixelHeight), maybe a ST_Rotation and certainly a ST_SetRotation.

There is already a ticket for ST_SetRotation (#482) but not for ST_PixelHeight, ST_PixelWidth and ST_Rotation.

We could close this one and create a ticket for them (or mention them in the specifications of future versions).

Agreed?

Agreed! I created #928 for ST_PixelWidth, #929 for ST_PixelHeight. How would ST_Rotation handle two different rotations (like when a pixel is diamond-shaped)?

[pracine]

How would ST_Rotation handle two different rotations (like when a pixel is diamond-shaped)?

I don't know… Your last proposition was to return NaN for diamond shaped… It's probably the best compromise.

[dzwarg]

Replying to pracine:

How would ST_Rotation handle two different rotations (like when a pixel is diamond-shaped)?

I don't know… Your last proposition was to return NaN for diamond shaped… It's probably the best compromise.

Great! Will do. Just opened #936 for ST_Rotation. Should rotations be reported in degrees or radians?

[pracine]

Follow ​http://postgis.refractions.net/docs/ST_Azimuth.html

[dzwarg]

Closing this issue, with tickets #928, #929, #482, and #936 containing the breakdown of the tasks discussed herein.

[robe]

Milestone renamed