[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgis-devel
Subject:    Re: [postgis-devel] Status of raster mapalgebra?
From:       Nicklas =?ISO-8859-1?Q?Av=E9n?= <nicklas.aven () jordogskog ! no>
Date:       2011-01-31 21:15:43
Message-ID: 1296508543.1896.56.camel () ubuntu64
[Download RAW message or body]

Thanks Pierre

I will take a look at the plpgsql-functions.

I understand that there is a lot of work to do. It will be exciting when
things are in place :-)

/Nicklas



On Mon, 2011-01-31 at 15:20 -0500, Pierre Racine wrote:
> Hi Nicklas,
> 
> > What is the status of map algebra functionality?
> 
> There is a one raster version on the way (Jorge what is the status?) and a two \
> raster version planned. You can see slow plpgsql prototypes of those two functions \
> in raster/script/plpgsql 
> > Is there any code that could be tested?
> 
> Just the plpgsql versions. But they might be sufficient to make a demo or proof of \
> concept. 
> > In beginning of Mars I will give a talk about PostGIS i Stockholm. I
> > will try to tell about the news in 2.0.
> 
> MapAlgebra will be a very progressive work:
> 
> 1) One raster version - Pixel by pixel
> 2) One raster version - Accepting neighbour pixels in expression
> 3) One raster version - Accepting neighbour pixels from the whole coverage (hence \
> getting raster values using world coordinates over the whole table instead of just \
> raster coordinates) 4) Two raster version
> 5) Two raster version working with non-aligned rasters (forcing resampling of one \
> to be aligned on the other one) 
> 1) might do it in 2.0.
> 2) maybe.
> The rest probably/certainly not. It will depend on the date of release.
> 5) need GDAL based ST_Resampling first (this is still far away).
> 
> > Most of my raster experience is about finding clear cuttings by
> > comparing satellite imagery from different years. It would have been
> > very nice to be able to show that in PostGIS. The software that were
> > used for that purpose was something called Enforma that as far as I
> > understand just compared band for band what had happened since last
> > year. The different bands give different result depending on what
> > wave-lengths the photosynthesis uses compared to what is absorbed to
> > naked ground and so on.
> 
> For this I guess you would need the two raster version computing difference between \
> two bands years after years. 
> > Will there be anything to try during February?
> 
> I suggest you use the plpgsql versions as a proof of concept and comment on their \
> usage. They might however be broken right now because of some change in the API but \
> they should be easy to repair. 
> > Am I right that map algebra will be the tool to use?
> 
> Yes. Something like:
> 
> SELECT ST_MapAlgebra(rast1, 1, rast1, 2, "rast2 - rast1") FROM yourrastertable \
> WHERE ST_Intersect(rast1, rast2) 
> Later MapAlgebra should be encapsulated by a number of specific functions. In your \
> case probably something like ST_Difference(raster1, band1, raster2, band2) 
> > I have no idea how much work there is to do so I don't know what I am
> > asking for.
> 
> The two raster version is very complicated (you must deal with nodata values, \
> non-aligned rasters). I'm working on an optimized version (setting large zones or \
> raster with memcpy when possible) which still a lot of work. 
> Pierre
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> 


_______________________________________________
postgis-devel mailing list
postgis-devel@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel


[prev in list] [next in list] [prev in thread] [next in thread]