QGIS » QGIS Application

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

1. run this in psql

---

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:

1. Where is the 4840000 coming from???

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