Bug report #643
GeoTIFF created with GRASS r.out.gdal do not display in QGIS
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  nobody - | ||
| Category: | GRASS | ||
| Affected QGIS version: | Regression?: | No | |
| Operating System: | All | Easy fix?: | No |
| Pull Request or Patch supplied: | Resolution: | fixed | |
| Crashes QGIS or corrupts data: | Copied to github as #: | 10702 |
Description
Example:
I have exported a GeoTIFF from GRASS, using r.out.gdal.
In the famous spearfish60 location:
g.region rast=vegcover r.out.gdal input=vegcover format=GTiff type=Byte output=vegcover.tif
The vegcover.tif looks OK in the gdalinfo output. It displays fine in OpenEV and GIMP. I can load it back into GRASS with r.in.gdal - values, extent and color table all are preserved.
QGIS however does not display anything after loading it. The map canvas extent and coordinates seem to be set according to raster extent and location, though. I can query the raster and reasonable values are reported. The problem is nothing is visible. No errors printed to the console AFAICT.
The GeoTIFF is attached.
Maciek
Associated revisions
Ignoring color ramps from 0.0 to 0.0 to be able to draw malformed TIFFs. Fixes #643
git-svn-id: http://svn.osgeo.org/qgis/branches/Release-0_8_0@6794 c8812cc2-4d05-0410-92ff-de0c093fc19c
History
#1
Updated by Magnus Homann about 17 years ago
The tiff has a GRASS color table that is zero. See:
$ gdalinfo vegcover.tif | grep COLOR
It's unclear what color tabel should have precedence, or if this is a malformed TIFF.
#2
Updated by Magnus Homann about 17 years ago
- Resolution set to fixed
- Status changed from Open to Closed
The excerpt below shows the metadata. I have changed qgis to ignore any ramps from 0.0 to 0.0. Hopefully, thsi doesn't break anything, while still allow malformed TIFF to be displayed. Fixed in .
Driver: GTiff/GeoTIFF
Size is 190, 140
Coordinate System is:
PROJCS["unnamed",
GEOGCS["NAD27",
DATUM["North_American_Datum_1927",
SPHEROID["Clarke 1866",6378206.4,294.9786982138982,
AUTHORITY[[EPSG""7008]],
AUTHORITY[[EPSG""6267]],
PRIMEM[[Greenwich]],
UNIT[[degree]],
AUTHORITY[[EPSG""4267]],
PROJECTION[[Transverse_Mercator]],
PARAMETER[[latitude_of_origin]],
PARAMETER[[central_meridian]],
PARAMETER[[scale_factor]],
PARAMETER[[false_easting]],
PARAMETER[[false_northing]],
UNIT["metre",1,
AUTHORITY[[EPSG""9001]],
AUTHORITY[[EPSG""26713]]
Origin = (590000.000000000000000,4928000.000000000000000)
Pixel Size = (100.000000000000000,-100.000000000000000)
Metadata:
AREA_OR_POINT=Area
Corner Coordinates:
Upper Left ( 590000.000, 4928000.000) (103d52'4.42"W, 44d30'5.97"N)
Lower Left ( 590000.000, 4914000.000) (103d52'13.17"W, 44d22'32.31"N)
Upper Right ( 609000.000, 4928000.000) (103d37'44.25"W, 44d29'56.54"N)
Lower Right ( 609000.000, 4914000.000) (103d37'54.84"W, 44d22'22.93"N)
Center ( 599500.000, 4921000.000) (103d44'59.16"W, 44d26'14.67"N)
Band 1 Block=190x43 Type=Byte, [[ColorInterp]]=Palette
[[NoData]] Value=255
Metadata:
COLOR_TABLE_RULES_COUNT=6
COLOR_TABLE_RULE_RGB_0=0.000000e+00 0.000000e+00 0 0 0 0 0 0
COLOR_TABLE_RULE_RGB_1=0.000000e+00 0.000000e+00 0 0 0 0 0 0
COLOR_TABLE_RULE_RGB_2=0.000000e+00 0.000000e+00 0 0 0 0 0 0
COLOR_TABLE_RULE_RGB_3=0.000000e+00 0.000000e+00 0 0 0 0 0 0
COLOR_TABLE_RULE_RGB_4=0.000000e+00 0.000000e+00 0 0 0 0 0 0
COLOR_TABLE_RULE_RGB_5=0.000000e+00 0.000000e+00 0 0 0 0 0 0
Color Table (RGB with 256 entries)
0: 0,0,0,255
1: 255,0,0,255
2: 255,255,0,255
3: 255,128,0,255
4: 0,0,255,255
5: 255,0,255,255
6: 0,255,0,255
7: 0,0,0,255
8: 0,0,0,255
9: 0,0,0,255
10: 0,0,0,255
11: 0,0,0,255
.
.
.
#3
Updated by Redmine Admin about 17 years ago
Thanks for the fix. It works. In the meantime Glynn Clemments fixed the issue in GRASS 6.3 CVS, so r.out.gdal GeoTIFF output has proper colortable and displays fine even without the hack.
Maciek
#4 Updated by Anonymous over 14 years ago
Milestone Version 0.8.1 deleted