<br>
<br><tt><font size=2>postgis-users-bounces@postgis.refractions.net wrote
on 06/03/2011 12:00:56 PM:<br>
<br>
> Right. But you can compute stats on the result of ST_Intersection()
<br>
> using ST_Area(geom)/areaOfOnePixel.  Since the results are vector,
<br>
> the ST_histogram function is useless here.<br>
</font></tt>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>> It is true that PostGIS raster do not allow yet
to reassemble raster<br>
> tiles into bigger rasters but you don't have to do that in order to
<br>
> compute histogram on a tiled coverage. Just compute the histogram
<br>
> for every tiles and aggregate the results using a GROUP BY query.
<br>
> (Bborie: shouldn't we have a ST_Histogram variant working on a whole<br>
> table like we have for the other stat functions?)<br>
</font></tt>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>> If the polygon area is small comparing with the
raster area you <br>
> should retile your raster coverage into smaller tiles so the query
<br>
> has to vectorize less useless raster area. It is important to index
<br>
> the coverage and to add "WHERE ST_Intersects()" in this
case. Make <br>
> sure also that both your raster coverage and your vector coverage
<br>
> have indexes. This makes a HUGE difference. I see that you don't do
<br>
> that in your tutorial. You can do it while loading your data with
<br>
> the "-I" option or afterward with a "CREATE INDEX"
query.<br>
</font></tt>
<br><tt><font size=2>Good catch. Fixed.</font></tt>
<br>
<br><tt><font size=2>> As I said we are very near to have a geometry
parameter to the stats<br>
> functions restricting the computation to defined area. Once we have
<br>
> this all your tutorial should be much shorter...<br>
</font></tt>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>The two things standing in my way appear to be "Objective
FV.02" and "Objective FV.03" on this page: </font></tt><a href=http://trac.osgeo.org/postgis/wiki/WKTRaster/PlanningAndFunding><tt><font size=2>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.<br>
</font></tt></a>
<br>
<br><tt><font size=2>Bryce</font></tt>