[postgis-devel] Raster todo list

George Silva georger.silva at gmail.com
Thu Jun 16 09:07:33 PDT 2011


I'm sorry for jumping in the discussion...I feel that the function bborie is
much like ST_Collect, am I right?

Could the name be the same? It might help bring together raster x geometry
functions.

Just a thought,

George

On Thu, Jun 16, 2011 at 1:00 PM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca>wrote:

> Hi Bborie,
>
> > ST_Resample:
> >
> > this would be adding the ability to change the scale (pixel size) and the
> origin
> > (upper-left corner) of a raster using the GDAL library.  How about
> de-skewing a
> > raster?
>
> I already wrote specifications for that function. I did not put them in the
> wiki yet though. I can do it ASAP.
>
> > ST_AsRaster:
> >
> > convert a geometry to a raster using the GDAL library
>
> I also have spec for that. Still have to put them in the wiki.
>
> > ST_Accum:
> >
> > be able to bring together a set of tiles to make one unified raster.  I
> really need
> > to be able to do the following:
> >
> > SELECT
> >       observation_date,
> >       ST_Accum(rast)
> > FROM tmax_2011
> > GROUP BY observation_date
> >
> > This function will entail a bunch of issues, such as irregular scales,
> unclean
> > overlap of tiles, skew and projection.
> >
> > ST_Clip:
> >
> > be able to clip/crop a raster using a geometry or raster as a mask
> >
> > I haven't had much time yet to think of the specifics for each function
> but I'll get
> > to each when I get there.
>
> Isn't it more something like ST_Union that you need? ST_Accum create an
> array of geometry. ST_Union merge them together.
>
> I think those two last functions should wrappers around an optimized
> version of two raster MapAlgebra. The non optimized version of Mapalgebra
> compute one pixel at a time.
>
> There should be an option in the two rasters version of mapalgebra
> (optimized or not) to say what we want the resulting raster area to be: same
> as the FIRST raster, same as the SECOND, same as the INTERSECTION of both or
> same as the UNION of both.
>
> INTERSECTION is very useful to implement ST_Clip  and UNION is very useful
> to implement ST_Union (or the merge of two rasters).
>
> When you use UNION, very often there are areas that do not overlap. For
> those areas you want to be able to provide an alternative expression for the
> missing data. This is also the case when they overlap but one of the raster
> pixel is nodata.
>
> Also when you use UNION, and where the two rasters expression do not apply.
> You can optimize the setting of these sub-areas quickly as block (like a
> memset), not pixel by pixel. You may want to set the whole sub-area to
> nodata, to a constant or to a copy of one of the two raster (this is the
> optimum case exploited by ST_Union).
>
> When you use intersection and the expression resume to 'rast1' you have a
> clip. You also, in this case, want to just copy the pixel values from the
> first raster to the second. This can be optimized by a ST_SetValues function
> just copying pixel values from one to the other.
>
> So in the end you have a very flexible Mapalgebra working on two rasters
> helping you to implement a bunch of other raster processes and optimized for
> the very useful case of doing Clips and Unions. In bonus you get some
> editing functions like ST_SetValues very usefull to implement who knows
> what...
>
> That how I see all this.
>
> Please have a look at script/plpgsql/st_mapalgebra.sql and
> script/plpgsql/st_mapalgebra_optimized.sql
>
> Pierre
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



-- 
George R. C. Silva

Desenvolvimento em GIS
http://geoprocessamento.net
http://blog.geoprocessamento.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20110616/60ae8f27/attachment.html>


More information about the postgis-devel mailing list