[postgis-users] Raster pixel value

Tom van Tilburg tom.van.tilburg at gmail.com
Tue Dec 6 06:40:51 PST 2011


Andreas,

I didn't have time to reproduce your problem yet. Did you have any 
succes by yourself on this issue?
Could it have something to do with counting the non-data values as 
value? This is what I experience with a similar function (ST_Clip) that 
consequently gave me the value '0' instead of the nodata value. The 
result of that is that the mean was often lower than expected.

Perhaps you could rewrite your previous example to something with 
auto-generated values in the script. That saves time in reproducing.

Cheers,
  Tom


On 25-11-2011 18:11, Andreas Forø Tollefsen wrote:
> Update:
>
> I think my suspicion is correct. If I do a ST_Summarystats().sum and 
> divide this on 36 my MAX value will be 1.
> Hence, I think the number of values counted and the number of 
> observations counted is not equal.
>
> New query:
> DROP TABLE IF EXISTS mountain_phil_cell;
>
> SELECT
> a.gid As gid,
> (ST_SummaryStats((ST_Union(ST_MapAlgebraExpr(ST_AsRaster(a.cell, 
> b.rast, '32BF'), b.rast, 'rast2', 
> '32BF','INTERSECTION','0','0',0))).rast, false)).sum / 36 As avgmnt
> INTO mountain_phil_cell
> FROM
> priogrid_land a LEFT JOIN
> mountain_phil b
>     ON ST_Intersects(a.cell, b.rast)
> GROUP BY a.gid
> ORDER BY a.gid;
>
>
> 2011/11/25 Andreas Forø Tollefsen <andreasft at gmail.com 
> <mailto:andreasft at gmail.com>>
>
>     A small note regarding this issue.
>
>     My problem is that I never get a mean value of 1 even if all
>     pixels inside the geometry is one.
>
>     Could this be because: 6x6 pixels goes into one polygon when
>     visually controlling. If each pixel has the value 1, then this
>     will be calculated as 36 / 36 = 1. However, if it calculates the
>     sum to be 36 and divide by a number higher than 36 pixels, then
>     the result will always be below 1.
>     What i am thinking is that while it sums up the pixel values
>     correctly, it does not count only the 36 pixels, but also
>     neighboring pixels. Therefore: 1+1+1+1...n36 / Number of pixels
>     higher than 36 will always lead to a number lower than 1.
>
>     Anyone who knows the functions well could probably answer this.
>
>     Best regards,
>     Andreas
>
>
>     2011/11/25 Andreas Forø Tollefsen <andreasft at gmail.com
>     <mailto:andreasft at gmail.com>>
>
>         Could this have to do with the tiling of the raster?
>         I will try to run the same query with a untiled mountain
>         raster to see if that changes anything.
>
>         Btw. When loading a tiled postgis raster into qgis it shows up
>         with many artifacts and no data areas. The same raster untiled
>         does not show up the same way.
>         Qgis bug?
>
>         Andreas
>
>         2011/11/25 Andreas Forø Tollefsen <andreasft at gmail.com
>         <mailto:andreasft at gmail.com>>
>
>             Hi,
>
>             Thanks for all of the suggestions. I will do some more
>             testing. However, as for suggestion 1 i think the pixel
>             size should be the same as the original raster or am I wrong?
>
>             Both the mean_mnt_bin raster and the priogrid_land
>             shapefile can be downloaded as zip (2 mb) here:
>             http://gisintersect.com/mean_mnt_bin.zip
>             http://gisintersect.com/priogrid_land.zip
>
>             Any help on getting the correct values would be very much
>             appreciated.
>
>             My query:
>             DROP TABLE IF EXISTS mountain_cell;
>
>             SELECT
>             a.gid As id,
>             (ST_SummaryStats((ST_Union(ST_MapAlgebraExpr(ST_AsRaster(a.cell,
>             b.rast, '32BF'), b.rast, 'rast2',
>             '32BF','INTERSECTION','0','0',0))).rast, false)).mean As
>             avgmnt
>             INTO mountain_cell
>             FROM
>             priogrid_land a LEFT JOIN
>             mountain b
>                 ON ST_Intersects(a.cell, b.rast)
>             GROUP BY a.gid
>             ORDER BY a.gid;
>
>
>
>
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20111206/54bf1874/attachment.html>


More information about the postgis-users mailing list