Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#1819 closed defect (fixed)

[raster] floating point issues with ST_World2RasterCoordX and ST_World2RasterCoordY

Reported by: Bborie Park Owned by: Bborie Park
Priority: medium Milestone: PostGIS 2.0.1
Component: raster Version: 2.0.x
Keywords: history Cc:

Description

For some rasters, I'm finding that the if I pass the upper left corner of a raster to ST_World2RasterCoord(X|Y), the function returns zero (0) instead of one (1). After doing some digging, the problem arises from the computation taking place in plpgsql.

Testing a plpgsql function calling the underlying C function rt_raster_geopoint_to_cell() that does the same process, the correct answer is consistently provided.

I'll try to post a concise example once I find one.

This should be backported to 2.0.x...

Change History (10)

comment:1 Changed 10 years ago by robe

Bborie, Are you planning to get to this before 2.0.1 is out or is it more involved? As a general rule, I think its better to mark things for the first micro version it will be available in. It's always the assumption that any fixes in the lower version are upported but not all fixes are backported.

comment:2 Changed 10 years ago by Bborie Park

Milestone: PostGIS 2.1.0PostGIS 2.0.1
Status: newassigned
Version: trunk2.0.x

robe,

Yes, I plan on getting this in before 2.0.1 (probably tomorrow). The error behavior (NOTICE vs ERROR) will differ in 2.0.1 vs 2.1 as it looks like the plpgsql version currently in 2.0 returns ERROR when it should be returning NOTICE.

I've changed the milestone and version...

comment:3 Changed 10 years ago by Bborie Park

Keywords: history added
Resolution: fixed
Status: assignedclosed

Fixed in r9738. NEWS updated in r9739.

I'll add a new ticket for 2.1 to correct the error behavior in 2.0 that is inconsistent of best practices.

comment:4 Changed 10 years ago by pracine

Did you make sure that only one of the upper left and the lower right corner (and not both) are converted to an actual raster coordinate. i.e. If the upper left corner returns 1 then the lower right corner should return width + 1. Otherwise, from tile to tile, you fall into inconsistencies.

comment:5 Changed 10 years ago by Bborie Park

I'm confused by your comment. All that I've done is remove the pure plpgsql code (which has floating-point issues) and instead call the C API's rt_raster_geopoint_to_cell function. This eliminated the cases that I was seeing where the upper left corner of a tile was return 0,0 instead of 1,1.

comment:6 Changed 10 years ago by pracine

I think it was the desired behaviour. A choice actually between the upper left corner is "inside" the raster of the lower right corner is "inside". The should not be both "inside" otherwise both the lower right corner of a tile AND the upper left corner of the adjacent corner would both fall into two tiles. Remember also that those functions work even if you provide coordinates outside the raster. If x is smaller than (or equal to) the x upper left then the resulting raster coordinate is smaller than (or equal to) 0.

comment:7 Changed 10 years ago by Bborie Park

This "choice" you are talking about doesn't exist in 2.0. If you want a user to choose, that would have to be in 2.1 as this would be a behavior change. The behavior in 2.0 is that the upper-left corner of a pixel is in the pixel while the lower-right corner of the pixel is outside the pixel.

comment:8 Changed 10 years ago by pracine

I know there is no "choice". There is a "rule"... Just wanted to make sure your change still follow the rule.

comment:9 Changed 10 years ago by Bborie Park

Oh yeah. The change I made didn't require any changes to the regression tests. Resulting behavior is identical.

comment:10 Changed 10 years ago by pracine

Great!

Note: See TracTickets for help on using tickets.