[postgis-devel] [PostGIS] #588: [raster] Implement the one raster version of ST_MapAlgebra

[Jorge Arévalo]

On Thu, Feb 17, 2011 at 3:32 PM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca> wrote:
> I did not have time to test it yet. How fast is it?
>

I've made a test with this query:

SELECT ST_Value(rast, 1, 1), ST_Value(ST_OldMapAlgebra(rast, 1, 'rast
+ 20', 'rast + 2', '2BUI'), 1, 1) FROM ST_TestRaster(0, 0, 101) rast;

(TestRaster creates a 100x100 px, 32BF, empty raster)

Comparing the C implementation and the PL/pgSQL implementation (both
of them following the same algorithm). The C version is slightly
faster, as average (111000 ms vs 113500 ms). As happened with
DumpAsPolygons, it needs some fine tunning...

Best regards,


-- 
Jorge Arévalo
Internet & Mobilty Division, DEIMOS
jorge.arevalo at deimos-space.com
http://es.linkedin.com/in/jorgearevalo80
http://mobility.grupodeimos.com/
http://gis4free.wordpress.com
http://geohash.org/ezjqgrgzz0g



>>-----Original Message-----
>>From: PostGIS [mailto:trac at osgeo.org]
>>Sent: 17 février 2011 07:44
>>Cc: postgis-devel at postgis.refractions.net
>>Subject: Re: [PostGIS] #588: [raster] Implement the one raster version of ST_MapAlgebra
>>
>>#588: [raster] Implement the one raster version of ST_MapAlgebra
>>-----------------------------+----------------------------------------------
>>  Reporter:  pracine         |       Owner:  jorgearevalo
>>      Type:  task            |      Status:  closed
>>  Priority:  medium          |   Milestone:  PostGIS 2.0.0
>> Component:  postgis raster  |     Version:  trunk
>>Resolution:  fixed           |    Keywords:
>>-----------------------------+----------------------------------------------
>>
>>Comment(by robe):
>>
>> That's the weird thing - everything was going good and then suddenly I
>> would get errors like SELECT CASE WHEN mod(200.00,2)  ... rast  (RAST does
>> not exist) errors.
>>
>> Though I can't trip it up now with a case:  These work fine for example,
>> but it wasn't the one I was testing yesterday (which is why I thought it
>> was one of those heisenburgs).
>>
>> However I do keep on getting a notice that my initial value is truncated
>> when I do things like this:
>>
>> ALTER TABLE dummy_rast ADD COLUMN map_rast raster;
>> UPDATE dummy_rast
>>   SET map_rast = st_mapalgebra(rast, 'CASE WHEN mod(rast,2) = 1 THEN rast
>> WHEN rast = 254 THEN 100 WHEN rast < 253 THEN mod(rast,4) ELSE rast END')
>> WHERE rid = 2;
>>
>> Is that one of those weird windows bugs?
>>
>> Gives warning:
>>
>>
>> {{{
>> WARNING:  Initial pixel value for 8BUI band got truncated from -128.000000
>> to 128
>> }}}
>>
>>
>> But result above looks right.
>>
>>
>> I think the other case with the PixelType not working was user error on my
>> part.  I had typed 2BB instead of 1BB or 2BUI.  I didn't get a warning
>> message or error, but it didn't convert the pixeltype -- it left it as
>> 8BUI.  I think maybe we should throw an error if someone types in an
>> invalid PixelType -- you know just for people like me :).  It wouldn't be
>> pleasant if you thought that you had a 2BB pixel band and 1 million
>> updates later, you realized it was really 8 BUI.
>>
>>--
>>Ticket URL: <https://trac.osgeo.org/postgis/ticket/588#comment:7>
>>PostGIS <http://trac.osgeo.org/postgis/>
>>The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view
>>into the subversion code repository of PostGIS project.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>