>> 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.
Right. >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. Right. It would even be of greater value for other functionalities even if, I think, it would be slower for the particular case of computing stats . >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. Those two objectives are still unfunded and unallocated. I think the approximation for FV.02 is probably a bit high since ST_AsRaster is planned as a wrapper around GDALRasterizeLayers() and we already have some functions linking with GDAL that you can mimic but I prefer to be conservative. There is already a crude pl/pgSQL version of ST_AsRaster in script/plpgsql/st_asraster.sql The time required to implement FV.03 (ST_Union()) depend on how you want to do it. You can base everything on a basic ST_Merge function which burn only the last, the first or the mean raster value when there is overlap or you can, as I was planning, use a two rasters version of ST_MapAlgebra (not yet implemented) to express the merging rule with a state and a final SQL expression. There is a plpgsql prototype of such a ST_Union function in script/plpgsql/st_union.sql. You basically pass a state and a final SQL expression to the ST_Union aggregate and ST_MapAlgebra take the expression computation in charge. A two rasters version of ST_MapAlgebra is hard to implement but most of the hard work is already done. There is two plpgsql prototypes of the two rasters version of ST_MapAlgebra. One in script/plpgsql/st_mapalgebra.sql and an optimized/unfinished one in st_mapalgebra_optimized.sql. Having a two rasters version of ST_MapAlgebra would be of great benefit to the project as it open millions of other possibilities. We almost had a Google summer of code for it but didn't. I would estimate the time to implement the first scenario (ST_Union with ST_Merge) to two to three weeks and the second scenario (ST_Union with ST_MapAlgebra) to two months. Please have a look at those plpgsql prototypes. Pierre _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
