#1819 closed defect (fixed)
[raster] floating point issues with ST_World2RasterCoordX and ST_World2RasterCoordY
| Reported by: | dustymugs | Owned by: | dustymugs |
|---|---|---|---|
| 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 by , 13 years ago
comment:2 by , 13 years ago
| Milestone: | PostGIS 2.1.0 → PostGIS 2.0.1 |
|---|---|
| Status: | new → assigned |
| Version: | trunk → 2.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 by , 13 years ago
| Keywords: | history added |
|---|---|
| Resolution: | → fixed |
| Status: | assigned → closed |
comment:4 by , 13 years ago
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 by , 13 years ago
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 by , 13 years ago
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 by , 13 years ago
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 by , 13 years ago
I know there is no "choice". There is a "rule"… Just wanted to make sure your change still follow the rule.
comment:9 by , 13 years ago
Oh yeah. The change I made didn't require any changes to the regression tests. Resulting behavior is identical.
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.