[gdal-dev] Re: Rasterlite / WSGI problem
radim.blazek at gmail.com
Wed Nov 30 02:14:37 EST 2011
I'll reply to myself in case anyone have the same problem.
Apache is linked to SQLite. SQLite from deb is not compiled with
rtree. WSGI is started as Apache fork, so the process has SQLite (from
/usr/lib/) already loaded and later explicit loading of SQLite lib
with rtree cannot help.
I solved it setting LD_LIBRARY_PATH to point to SQLite with rtree in
/etc/apache2/envvars. I had also tried to compile GDAL staticaly
linked to SpatiaLite but it was not working.
BTW, if RasterliteBand::IReadBlock fails, it does not return an error
and silently sets image to black (rasterlitedataset.cpp:98):
OGRLayerH hSQLLyr = OGR_DS_ExecuteSQL(poGDS->hDS, osSQL.c_str(),
if (hSQLLyr == NULL)
memset(pImage, 0, nBlockXSize * nBlockYSize * nDataTypeSize);
Is it OK?
On Sat, Nov 26, 2011 at 11:45 AM, Radim Blazek <radim.blazek at gmail.com> wrote:
> We cannot get Mapserver python mapscript running as WSGI with
> Rasterlite data working. Only a black rectangle is drawn instead of
> the raster. The rectangle is drawn on the right place however.
> Rendering takes very little time, so it seems that no image processing
> is done. Spatialite/OGR works correctly (using geometry column from
> raster _metadata table). All other raster/vector data work well.
> The strange thing is, that everything works well, if exactly the same
> configuration is run as CGI.
> I thougt that threads could be a problem, so I disabled treads where
> possible, but no effect.
> Rasterlite data: JPEG or EPSILON, JPEG or EPSILON overviews, SRID correctly set
> GDAL 1.8.1 --with-threads=no
> Mapserver 6.0.1 patched to use GDALOpen instead of GDALOpenShared
> WSGI: processes=1 threads=1
More information about the gdal-dev