[GIS] World file in georeferenced file does not work in QGIS

coordinate systemqgisrasterworld-file

In QGIS 2.18.3 on Windows 7, I have geotiffs that were created by georeferencing rasters in ArcGIS 10.2. These rasters do not project correctly in QGIS.

Opening images georeferenced (.aux.xml) in ArcMap in QGIS? refers to the world file associated with each raster as being necessary for proper projection. The world files exist for each raster. However, the created files end with x, as in ".tfwx" and the question I referred to said that x at the end is approximate and that could cause a problem for QGIS.

I closed QGIS, edited the .tfwx to .tfw, and opened the file in a new instance of QGIS, but the raster still doesn't project properly. I tried warping the file and that didn't fix it. (I have several rasters and would rather not reproject them anyway.)

In Properties>Metadata>Origin the values for one of the rasters is 0,601, which doesn't seem correct. They all project fine in ArcGIS. How do I get the files to project correctly in QGIS?

Edit per request for tfwx and aux.xml:

Here is the tfw(x):

1.3609845791669659
0.013698921791920324
0.013698921791776822
-1.3609845791682424
633950.54191826226
3686572.8424918195

aux.xml:

<PolynomialOrder>1</PolynomialOrder>
<SpatialReference xsi:type="typens:ProjectedCoordinateSystem">

PROJCS["NAD_1983_UTM_Zone_14",
GEOGCS["GCS_North_American_1983",
DATUM["D_North_American_1983",
SPHEROID["GRS_1980",6378137.0,298.257222101]],
PRIMEM["Greenwich",0.0],
UNIT["Degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["False_Easting",500000.0],
PARAMETER["False_Northing",0.0],
PARAMETER["Central_Meridian",-99.0],
PARAMETER["Scale_Factor",0.9996],
PARAMETER["Latitude_Of_Origin",0.0],
UNIT["Meter",1.0],
AUTHORITY["EPSG",26914]]
    <XOrigin>-5120900</XOrigin>
    <YOrigin>-9998100</YOrigin>
    <XYScale>450445547.3910538</XYScale>
    <ZOrigin>-100000</ZOrigin>
    <ZScale>10000</ZScale>
    <MOrigin>-100000</MOrigin>
    <MScale>10000</MScale>
    <XYTolerance>0.001</XYTolerance>
    <ZTolerance>0.001</ZTolerance>
    <MTolerance>0.001</MTolerance>
    <HighPrecision>true</HighPrecision>
    <WKID>26914</WKID>
    <LatestWKID>26914</LatestWKID>
  </SpatialReference>
  <CoeffX xsi:type="typens:ArrayOfDouble">
    <Double>633958.08762850869</Double>
    <Double>1.3609845791669402</Double>
    <Double>-0.013698921791817191</Double>
  </CoeffX>
  <CoeffY xsi:type="typens:ArrayOfDouble">
    <Double>3685755.5644025686</Double>
    <Double>0.013698921791817191</Double>
    <Double>1.3609845791669402</Double>
  </CoeffY>
  <InverseCoeffX xsi:type="typens:ArrayOfDouble">
    <Double>-493017.26483040652</Double>
    <Double>0.73468774906927536</Double>
    <Double>0.0073949625660466234</Double>
  </InverseCoeffX>
  <InverseCoeffY xsi:type="typens:ArrayOfDouble">
    <Double>-2703191.3629040248</Double>
    <Double>-0.0073949625660466077</Double>
    <Double>0.73468774906927548</Double>
  </InverseCoeffY>

Sorry this edit took so long. It took me a while to figure out how to get the XML to show up without being garbled.

Best Answer

Georeferencing Tif images in ArcGIS 10.2 results to following files: *.tfwx or *.tfw, and *.aux.xml. *.tfw seems to be written, if only affine transformation is involved, otherwise *.twfx.

I loaded some ArcGIS georeferenced images into QGIS and find, that QGIS recognized the coordinate system, but not the georeference parameters from .tfw/.tfwx files. I suppose that ArcGIS writes coordinate system information into the image without changing the file attributes (eg file creation date keeps unchanged).

GDAL, as used by QGIS to read the image, uses the *.tfw file, if NO GEOREFERENCE INFORMATION IS FOUND IN the image file (according GDAL documentation).

To verify this, I again saved the georeferenced image with an image viewer. Now QGIS does not recognize a coordinate system, but takes the information from the *.tfw file. A *.prj file was not accepted.

By setting the coordinate system explicitly as layer properties QGIS is able to display the image correctly (supposed only affine transformation was used).

Related Question