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

[Bborie Park]

On Sat, May 21, 2011 at 7:54 PM, Paragon Corporation <lr at pcorp.us> 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.
>

There are some C tests for the api and wkb output but everything else
looks to be in-db 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)
>

I completely forgot about using CUnit.  I'll take a look as I'd rather
use C instead of python.  I'm trying to avoid python as that is yet
another dependency and the hope that eventually someone will write a
C-based replacement for raster2pgsql.py.

> 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.
>

That is very strange.  The python as written looks fine.  You can
always try the rtgdalraster.py script in raster/scripts/python in 8.4
as that is my stupidly simple client for dumping GDAL raster outputs.
The bash script in either of the attached files for ticket #957 makes
use of that python client.

> 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;
>

Oops.  Fixed that in r7206.  The stupid warning is being stupid.

>  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.
>

You could always try out the ST_Reclass function.  Pierre seems to
know the proper set of reclassification expressions to generate
"pretty" RGB color ramps.  I have a bad habit where I end up getting
lazy and using ArcMap or ENVI to do the "pretty" things for me.

The pele example works great when outputted through ST_AsTIFF
ST_AsJPEG and ST_AsPNG and checked using a browser, gimp or photoshop.

> 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.  I just might have to take you up on the offer.

-bborie