[postgis-users] Basic postgis raster questions

[Bryce L Nordgren]

postgis-users-bounces at postgis.refractions.net wrote on 06/03/2011 12:00:56 
PM:

> Right. But you can compute stats on the result of ST_Intersection() 
> using ST_Area(geom)/areaOfOnePixel.  Since the results are vector, 
> the ST_histogram function is useless here.

That's basically the approach I started to take. Unfortunately, it's 
taking a fair bit of time because the rasters are a bit larger than 
optimum for this approach. Today I figured out how to do it in ENVI, so 
there's somewhat less pressure.

> It is true that PostGIS raster do not allow yet to reassemble raster
> tiles into bigger rasters but you don't have to do that in order to 
> compute histogram on a tiled coverage. Just compute the histogram 
> for every tiles and aggregate the results using a GROUP BY query. 
> (Bborie: shouldn't we have a ST_Histogram variant working on a whole
> table like we have for the other stat functions?)

I may be mistaken, but I did not see a way to ensure that all bins are 
constant for the individual runs of ST_Histogram on each tile. You can set 
the number of bins and the width of the bins, but each tile will have its 
own unique min/max values, which will move the bins around. Without 
constant bins, there's no way the results can be aggregated.

> If the polygon area is small comparing with the raster area you 
> should retile your raster coverage into smaller tiles so the query 
> has to vectorize less useless raster area. It is important to index 
> the coverage and to add "WHERE ST_Intersects()" in this case. Make 
> sure also that both your raster coverage and your vector coverage 
> have indexes. This makes a HUGE difference. I see that you don't do 
> that in your tutorial. You can do it while loading your data with 
> the "-I" option or afterward with a "CREATE INDEX" query.

Good catch. Fixed.

> As I said we are very near to have a geometry parameter to the stats
> functions restricting the computation to defined area. Once we have 
> this all your tutorial should be much shorter...

I may be missing the boat here, but it seems to me that a version of 
ST_Intersection() which returns a raster would eliminate the need for a 
separate geometry parameter, and would be more in line with the spirit of 
"seamless vector/raster" processing. It also would seem that your separate 
geometry parameter would behave very much like a raster-returning 
ST_Intersection(), except that it is only usable "vicariously" via the 
stats functions.

The two things standing in my way appear to be "Objective FV.02" and 
"Objective FV.03" on this page: 
http://trac.osgeo.org/postgis/wiki/WKTRaster/PlanningAndFunding   I'm 
curious if the page is accurate. Are these activities still unfunded and 
unallocated, and are 4 weeks/4800USD (FV.02) and 2 weeks/2400USD (FV.03) 
still considered a reasonable estimate of the effort required to implement 
these items? Don't get excited, but if I'm even thinking of running around 
with my hand out for money, I need ballpark figures.


Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20110603/13952d75/attachment.html>