Opened 9 years ago

Closed 8 years ago

Last modified 2 years ago

#582 closed defect (duplicate)

[raster] Create functions returning correct pixel size calculations

Reported by: dzwarg Owned by: dzwarg
Priority: medium Milestone: PostGIS Fund Me
Component: raster Version: master
Keywords: Cc:

Description

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(A2 + D2), and the true pixel height is actually sqrt(B2 + E2).

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?

Change History (14)

comment:1 Changed 9 years ago by dzwarg

Those equations should be:

true pixel width: sqrt(A2 + D2) true pixel height: sqrt(B2 + E2)

comment:2 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by pracine

Milestone: WKTRaster 0.1.6PostGIS 2.0.0

comment:5 Changed 9 years ago by pracine

Version: 1.5.Xtrunk

comment:6 Changed 9 years ago by pracine

Summary: [wktraster] Correct pixel size calculations[raster] Correct pixel size calculations

comment:7 Changed 9 years ago by pracine

Milestone: PostGIS 2.0.0PostGIS Raster Future
Summary: [raster] Correct pixel size calculations[raster] Create functions returning correct pixel size calculations

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?

comment:8 in reply to:  7 ; Changed 9 years ago by 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)?

comment:9 in reply to:  8 ; Changed 9 years ago by 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.

comment:10 in reply to:  9 Changed 9 years ago by 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?

comment:12 Changed 8 years ago by dzwarg

Resolution: duplicate
Status: newclosed

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

comment:13 Changed 8 years ago by pracine

Milestone: PostGIS Raster FuturePostGIS Future

comment:14 Changed 2 years ago by robe

Milestone: PostGIS FuturePostGIS Fund Me

Milestone renamed

Note: See TracTickets for help on using tickets.