qgib
commented
11 years ago Author Name: Graeme Bell (Graeme Bell)
1) Tested in windows: qgis 1.9 fcf108d, Mac 1.8.0 Windows 1.8.0 They all behave the same as Mac 1.9dev. So the hard crash only seems to happen in Linux 1.8 version.
But the bad extents/mostly missing tiles exists in all versions/platforms.
2) Upgraded to postgis 2.0.2 (built on gdal 1.10dev) and re-tested. No change.
POSTGIS="2.0.2 r10789" GEOS="3.3.6-CAPI-1.7.6" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10dev, released 2011/12/29" LIBXML="2.8.0" TOPOLOGY RASTER
Author Name: Graeme Bell (Graeme Bell) Original Redmine Issue: 6829 Affected QGIS version: master
(Blocker: can't do anything with generated rasters till this is fixed. Unsure if core qgis or postgis-raster bug).
General description: Bugs in raster rendering or extent calcuation. Test case code provided to allow it to be quickly reproduced, and tested on 2 builds of Qgis on two OS (details at end).
Start by disabling 'on the fly reprojection' in qgis.
Bug 1 - no display of most of raster.
drop table bigtest, bigrast; create table bigtest (row_number serial, x int, y int);
insert into bigtest (x, y) select a,b from generate_series(-80000,1120000-1,100000) a, generate_series(6440000,7950000-1,100000) b;
create table bigrast (rid serial primary key, rast raster);
insert into bigrast
select row_number, ST_MakeEmptyRaster(100,100,x,y,1000,-1000,0,0,25833) from bigtest;
update bigrast
set rast=st_addband(rast, '1BB'::text, 1,0);
SELECT AddRasterConstraints('bigrast'::name, 'rast'::name);
This sets up a test raster covering norway in UTM33 at low resolution.
Add the layer to QGis canvas using Database/DB manager.
Expected result: Should be a black box from -80000, 8040000 top left to 1120000, 6440000 bottom right
Actual result:
In both versions of QGIS, generated appearance is a thin black strip from -80000, 6440000 top left to 1120000, 6340000. e.g. one row of tiles, most of the raster is missing.
Layer extent given in properties/metadata as:
-80000, 4840000 112000, 6440000
This is wrong.
In postgis:
select ST_Raster2WorldCoordY(rast,1) from bigrast;
yields correct values.
Notes:
Where is the 4840000 coming from???
I believe qgis may be cropping the raster tiles with an upside down, incorrect extent somehow. Is it calculating extent for itself using pixel scale settings and top left position - rather than via postgis extents? Is it interpreting the 'y-pixel scale' wrong and forgetting to invert it?
I get the same results from the linux 1.8 and Macos 1.9dev versions.
Bug 2
Similar, but this time a positive y-scale pixel size value. This shouldn't work, but does.
drop table bigtest, bigrast;
create table bigtest (row_number serial, x int, y int);
insert into bigtest (x, y) select a,b from generate_series(-80000,1120000-1,100000) a, generate_series(6440000,7950000-1,100000) b;
create table bigrast (rid serial primary key, rast raster);
insert into bigrast
select row_number, ST_MakeEmptyRaster(100,100,x,y,1000,1000,0,0,25833) from bigtest;
update bigrast
set rast=st_addband(rast, '1BB'::text, 1,0);
SELECT AddRasterConstraints('bigrast'::name, 'rast'::name);
LINUX 1.8 Add to qgis with DB Manager -> QGis implodes - hard crash/core dump!
Debug crash output here http://pastebin.com/U3Htd6p7
MACOS 1.9 Displays the correct raster output that was expected for bug1 test case! (but shouldn't)
N.B. using a positive y-scale pixel size is the change. This was an attempt to stop the extents being made 'upside down' as in test1.
However, y-scale should be negative e.g. where it is auto-set by postgis raster:
http://postgis.refractions.net/documentation/manual-2.0/RT_ST_MakeEmptyRaster.html
"The last version use a single parameter to specify the pixel size (pixelsize). scalex is set to this argument and scaley is set to the negative value of this argument. skewx and skewy are set to 0."
also http://en.wikipedia.org/wiki/World_file
"Line 4: E: y component of the pixel height (y-scale), almost always negative"
I believe that a negative y-pixel size is the correct way to represent things. I think there is at least one bug in how qgis interprets y-pixel scale and how it calculates the extents of the coverage.
Tested in Fedora Linux with this build:
QGIS version 1.8.0-Lisboa QGIS code revision exported Compiled against Qt 4.8.2 Running against Qt 4.8.3 Compiled against GDAL/OGR 1.9.1 Running against GDAL/OGR 1.9.1 GEOS Version 3.3.2 PostgreSQL Client Version 9.1.4 SpatiaLite Version 2.4.0 QWT Version 5.2.2
And MacOS X Mountain Lion with this build:
QGIS version 1.9.0-Master QGIS code revision 9dd4a92 Compiled against Qt 4.8.3 Running against Qt 4.8.3 Compiled against GDAL/OGR 1.9.1 Running against GDAL/OGR 1.9.2 GEOS Version 3.3.5 PostgreSQL Client Version 9.1.6 SpatiaLite Version 3.0.1 QWT Version 6.0.1 PROJ.4 Version 480 QScintilla2 Version 2.6.2
$ postgres --version postgres (PostgreSQL) 9.2.1 postgis is version 2.0.1