[wktraster] ST_SetValue is changing the raster

[robe]

I'm not sure if this is a bug or not, but it is inconsistent with the way PostGIS functions, other raster functions and all PostgreSQL functions I know about work.

When I do this

SELECT (foo.geomval).val, ST_AsText(ST_Union((foo.geomval).geom))
FROM (SELECT ST_DumpAsPolygons(ST_SetValue(rast,1,ST_Point(3427927.75, 5793243.95),50)) As geomval
FROM dummy_rast
where rid = 2) As foo
WHERE (foo.geomval).val < 250
GROUP BY (foo.geomval).val;

And then do this

SELECT (foo.geomval).val, ST_AsText(ST_Union((foo.geomval).geom))
FROM (SELECT ST_DumpAsPolygons(rast,1) As geomval
FROM dummy_rast
where rid = 2) As foo
WHERE (foo.geomval).val < 250
GROUP BY (foo.geomval).val;

I'm seeing that the underlying raster has changed value since both give the same answer.

I would expect to have to do this:

UPDATE dummy_rast SET rast =   ST_SetValue(rast,1,ST_Point(3427927.75, 5793243.95),50)

I suppose its more efficient this way, but wondering if it may not be better to call this inplace edit or something else — so people don't assume it behaves like all the other ST_Set/ST_Add functions

[pracine]

1) Could you do this to demonstrate that the stored raster was actually edited:

SELECT ST_Value(rast, ST_Point(3427927.75, 5793243.95)) As val FROM dummy_rast

then:

SELECT ST_Value(ST_SetValue(rast, ST_Point(3427927.75, 5793243.95),50), ST_Point(3427927.75, 5793243.95)) As val FROM dummy_rast

and then:

SELECT ST_Value(rast, ST_Point(3427927.75, 5793243.95)) As val FROM dummy_rast

2) Could you do this:

SELECT ST_BandPixelType(rast) FROM dummy_rast

I think you got twice the same result because the pixel value was actually not set because 50 is out of the possible value range for this band. Let see…

[robe]

Pierre,

Sorry had a type in my query — here is the full From help manual

drop table IF EXISTS dummy_rast;
CREATE TABLE dummy_rast(rid integer, rast raster);
INSERT INTO dummy_rast(rid, rast)
VALUES (1,
('01' -- little endian (uint8 ndr)
|| 
'0000' -- version (uint16 0)
||
'0000' -- nBands (uint16 0)
||
'0000000000000040' -- scaleX (float64 2)
||
'0000000000000840' -- scaleY (float64 3)
||
'000000000000E03F' -- ipX (float64 0.5)
||
'000000000000E03F' -- ipY (float64 0.5)
||
'0000000000000000' -- skewX (float64 0)
||
'0000000000000000' -- skewY (float64 0)
||
'00000000' -- SRID (int32 0)
||
'0A00' -- width (uint16 10)
||
'1400' -- height (uint16 20)
)::raster
),
-- Raster: 5 x 5 pixels, 3 bands, PT_8BUI pixel type, NODATA = 0
(2,  ('01000003009A9999999999A93F9A9999999999A9BF000000E02B274A' ||
'41000000007719564100000000000000000000000000000000FFFFFFFF050005000400FDFEFDFEFEFDFEFEFDF9FAFEF' ||
'EFCF9FBFDFEFEFDFCFAFEFEFE04004E627AADD16076B4F9FE6370A9F5FE59637AB0E54F58617087040046566487A1506CA2E3FA5A6CAFFBFE4D566DA4CB3E454C5665')::raster);
  

 SELECT ST_Value(rast, ST_Point(3427927.75, 5793243.95)) As val FROM
 dummy_rast where rid = 2

— returns 253

  SELECT ST_SetValue(rast, ST_Point(3427927.75, 5793243.95),50) As val FROM
 dummy_rast where rid = 2;

-- then run again
 SELECT ST_Value(rast, ST_Point(3427927.75, 5793243.95)) As val FROM
 dummy_rast where rid = 2;

Returns 50.

This is running on PostgreSQL 9.0 Windows if it makes a difference. Haven't tried on 8.4 or 8.3 yet.

[pracine]

Interestingly enough, this problem arise only with raster having 3 bands. I have reduced the test case to 1 band and 2 bands rasters and I can't reproduce the problem. However when there is 3 band I can…

I'll try to see what is magic with 3 band rasters in the core…

[pracine]

Fixed in r5759.