[postgis-devel] Out of DB regression tests for ST_AsGDALRaster

[Chris Hodgson]

I have to admit that I haven't been paying too close attention to the 
progress of raster. My only comment would be that it must be scripted to 
run with all the other tests and that it runs on all the supported 
platforms ... so ya, python sounds like the best option for a more 
customized regression test of the external output, while c-unit would be 
the choice for testing the internal parts of the code.

Chris

Paragon Corporation wrote:
> I'm not sure what others think of this.  I would be okay with testing with
> python.  In fact I think raster already has some out of db python tests.
>
> Ideally though:  It should follow the same tests we do for the rest of the
> system and for that we use Cunit to do out of db tests.  If that's too much
> of a hassle for your tests, then I would personally be okay with you using
> python scripts since that's a requirement to use the raster2pgsql.py anyway
> so you actually already have to use python to test your raster2pgsql loader
> anyway.
>
> +1
>
> Wait for rest of PSC folks to make their comments. (HINT HINT PSC)
>
> If you want to experiment with using C-Unit, the instructions are here:
> http://trac.osgeo.org/postgis/wiki/DevWikiCUnit
>
> And like I send that is the standard for non-raster PostGIS we use.  Some
> examples of tests are in /trunk/liblwgeom/cunit
>
> Speaking of Python, I've been using plpython to test your raster output
> functions with a script that looks like this (but to be honest I don't
> really know python -- just copy other people's stuff)
> And some of my boston aerial data that I was hoping to eventually play
> around with to extrude different vector features like building footprint
> (lofty dream I know)
>
> CREATE OR REPLACE FUNCTION writeraster(filename text,img bytea)
>   RETURNS text
> AS $$
>     f = open('/postgis_images/' + filename, "w")
>     f.write(img)
>     return("done")
> $$ LANGUAGE plpythonu;
>
> SELECT writeraster('ab' || rid::text || '.tiff',ST_AsTIFF(rast,
> ARRAY['COMPRESS=DEFLATE', 'ZLEVEL=9']))
> FROM o_4_boston limit 100;
>
> SELECT writeraster('ab' || rid::text || '.tiff',ST_AsTIFF(rast)
> FROM o_4_boston limit 100;
>
> Anyrate -- works great on my 9.1 install but my 8.4 install doesn't generate
> readable images.  It could be very well a flaw in PLPython 8.4.
>
> Outputting ST_AsPNG doesn't work on any of my installs (I mean in generating
> readable images).
> In fact it throws a stupid warning for this particular data  if I don't
> specify the bands that I have too many when I only have 3 bands. Or at least
> ST_NumBands returns 3.
>
> SELECT writeraster('ab' || rid::text || '.png',ST_AsPNG(rast))
> FROM o_4_boston limit 100;
>
>   I'll next test with .NET and PHP to rule out PLPython idiosyncracies.  It
> was just easier to whip up a PLPython example and one I can easily throw
> into a torture test to stress test things.
>
>
> The ST_AsJPEG for this dataset always returns black and white, but I think
> it could be because my pixel ranges are higher than 256.  As I recall, I
> think for the pele example you've been playing with it works fine.
>
> Anyrate if you are interested in this dataset, I can provide these aerials
> as a download file -- the sample zipped is about 30 MB, but I can throw on
> my server for download since its publically available data.
>
> Thanks,
> Regina
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>