Bug report #6568

Problem with GeoTIFF CRS in qGis 1.8.0 linux

Added by Pavel M. about 12 years ago. Updated over 10 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:-
Affected QGIS version:1.8.0 Regression?:No
Operating System:linux Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:15766

Description

I've tried to load the same GeoTiff file into qGis 1.8.0 Desktop on WinXP and Ubuntu 12.04. While on Windows it just loads and is displayed right away, on linux it asks me to specify CRS for the file, like it is not present in the file. After I select a CRS from the list, it is then displayed where it should be.
It is either a bug in linux qGis, or there is something wrong with geotiff file. Please help me find what's going on inside.

Steps to reproduce:
1. Start qgis desktop
2. in a new empty project add a new raster layer (select attached geotiff file)
3. This should be it, and file should be displayed (and it does in windows, but not on linux)

test.tiff (11.4 KB) Pavel M., 2012-10-24 10:41 PM

History

#1 Updated by Giovanni Manghi about 12 years ago

  • Affected QGIS version changed from master to 1.8.0
  • Status changed from Open to Feedback
  • Target version set to Version 2.0.0

How do you have configured QGIS (on both systems) in

settings -> options -> crs -> crs for new layers?

I just tested your tif in my ubuntu 12.04 installation and qgis recognize the CRS as a custom one, specifically

+proj=tmerc +lat_0=36.66666666666666 +lon_0=-88.33333333333333 +k=0.9999749999999999 +x_0=152400.3048006096 +y_0=0 +ellps=clrk66 +nadgrids=@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat +units=m +no_defs

so I cannot confirm the issue.

#2 Updated by Pavel M. about 12 years ago

I get exactly these values on windows machine too. However the file is supposed to have NAD27 CRS (EPSG:26771) like this:

+proj=tmerc +lat_0=36.66666666666666 +lon_0=-88.33333333333333 +k=0.9999749999999999 +x_0=152400.3048006096 +y_0=0 +ellps=clrk66 +datum=NAD27 +units=us-ft +no_defs.

uDig and ENVI do recognize file contents as NAD27, so it's kinda weird that qGis creates a custom CRS for the file.

Seems I'll reinstall qGis on ubuntu, just in case I've done something to ubuntu installation.

settings->crs are identical on both machines and are set to "ask for CRS"

#3 Updated by Giovanni Manghi almost 12 years ago

Pavel M. wrote:

I get exactly these values on windows machine too. However the file is supposed to have NAD27 CRS (EPSG:26771) like this:

+proj=tmerc +lat_0=36.66666666666666 +lon_0=-88.33333333333333 +k=0.9999749999999999 +x_0=152400.3048006096 +y_0=0 +ellps=clrk66 +datum=NAD27 +units=us-ft +no_defs.

uDig and ENVI do recognize file contents as NAD27, so it's kinda weird that qGis creates a custom CRS for the file.

Seems I'll reinstall qGis on ubuntu, just in case I've done something to ubuntu installation.

settings->crs are identical on both machines and are set to "ask for CRS"

what is the status of this ticket?

this is what gdalinfo says about your sample, is this correct?

PROJCS["NAD27 / Illinois East",
GEOGCS["NAD27",
DATUM["North_American_Datum_1927",
SPHEROID["Clarke 1866",6378206.4,294.9786982139006,
AUTHORITY["EPSG","7008"]],
AUTHORITY["EPSG","6267"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4267"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",36.66666666666666],
PARAMETER["central_meridian",-88.33333333333333],
PARAMETER["scale_factor",0.999975],
PARAMETER["false_easting",152400.3048006096],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (681480.000000000000000,1913050.000000000000000)
Pixel Size = (545.885714285715950,-534.582456140350020)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_RESOLUTIONUNIT=1 (unitless)
TIFFTAG_XRESOLUTION=1
TIFFTAG_YRESOLUTION=1
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 681480.000, 1913050.000) ( 80d19'53.25"W, 53d36'45.63"N)
Lower Left ( 681480.000, 1882578.800) ( 80d22'57.49"W, 53d20'29.53"N)
Upper Right ( 704407.200, 1913050.000) ( 79d59'19.17"W, 53d35'20.77"N)
Lower Right ( 704407.200, 1882578.800) ( 80d 2'31.08"W, 53d19' 5.49"N)
Center ( 692943.600, 1897814.400) ( 80d11'10.41"W, 53d27'55.81"N)
Band 1 Block=16x16 Type=Byte, ColorInterp=Gray
Band 2 Block=16x16 Type=Byte, ColorInterp=Undefined
Band 3 Block=16x16 Type=Byte, ColorInterp=Undefined
Band 4 Block=16x16 Type=Byte, ColorInterp=Undefined

#4 Updated by Pavel M. almost 12 years ago

Yes, that seems correct. So, the problem seems to be not in gdal lib.

Giovanni Manghi wrote:

this is what gdalinfo says about your sample, is this correct?

PROJCS["NAD27 / Illinois East",
GEOGCS["NAD27",
DATUM["North_American_Datum_1927",
SPHEROID["Clarke 1866",6378206.4,294.9786982139006,
AUTHORITY["EPSG","7008"]],
AUTHORITY["EPSG","6267"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4267"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",36.66666666666666],
PARAMETER["central_meridian",-88.33333333333333],
PARAMETER["scale_factor",0.999975],
PARAMETER["false_easting",152400.3048006096],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (681480.000000000000000,1913050.000000000000000)
Pixel Size = (545.885714285715950,-534.582456140350020)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_RESOLUTIONUNIT=1 (unitless)
TIFFTAG_XRESOLUTION=1
TIFFTAG_YRESOLUTION=1
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 681480.000, 1913050.000) ( 80d19'53.25"W, 53d36'45.63"N)
Lower Left ( 681480.000, 1882578.800) ( 80d22'57.49"W, 53d20'29.53"N)
Upper Right ( 704407.200, 1913050.000) ( 79d59'19.17"W, 53d35'20.77"N)
Lower Right ( 704407.200, 1882578.800) ( 80d 2'31.08"W, 53d19' 5.49"N)
Center ( 692943.600, 1897814.400) ( 80d11'10.41"W, 53d27'55.81"N)
Band 1 Block=16x16 Type=Byte, ColorInterp=Gray
Band 2 Block=16x16 Type=Byte, ColorInterp=Undefined
Band 3 Block=16x16 Type=Byte, ColorInterp=Undefined
Band 4 Block=16x16 Type=Byte, ColorInterp=Undefined

#5 Updated by Jürgen Fischer over 10 years ago

  • Status changed from Feedback to Closed

probably meanwhile fixed - feel free to reopen if it's still there

Also available in: Atom PDF