7

For several months, I have been georeferencing files manually using the Georeferencer plugin within QGIS. I am now attempting to automate this process using GDAL. The Georeferencer provides a "Generate GDAL script" option, which creates the following commands:

gdal_translate -of GTiff -gcp 774.73 -338 -88.52 34.37 -gcp 1012.17 -215.136 -81.22 27.48 -gcp 972.709 -486.055 -77.76 36.67 asciiMAE20121001.asc testoutput1
gdalwarp -r near -order 1 -co COMPRESS=NONE testoutput1 testoutput2

When I run this script, however, the georeferenced raster is placed about 40 degrees further west than where it should be, and 7 degrees further south. Manually using the Georeferencer plugin continues to georeference the raster correctly. I think the problem is with the gdalwarp, because the raster is just shifted too far from where it should be. The placement of the values within it appears to be correct, so it looks like the gdal_translate worked correctly.

Does anyone know why the GDAL script produced by the Georeferencer would produce a raster displaced from the raster produced manually by the plugin?

Improve this question
15
  • Take gdalinfo from both variants. It may be that the command line commands do not set the projection correctly.
    – user30184
    Oct 10, 2014 at 14:53
  • 1
    btw, I recently asked a question using the same process. Might be a useful comparison: gis.stackexchange.com/questions/116672/…
    – djq
    Oct 10, 2014 at 14:59
  • Also, another useful example: mapbox.com/blog/georeferencing-satellite-geoeye
    – djq
    Oct 10, 2014 at 14:59
  • 1
    Have a try by adding -s_srs epsg:1234 -t_srs epsg:1234into your generated gdalwarp command. Change 1234 into the projection of your ground control points.
    – user30184
    Oct 10, 2014 at 15:01
  • 2
    Yes, we would need test data for repeating the issue. What I think is that QGIS writes wrong pixel/line offsets to gdalwarp command. Notice that in all your GCPs the line offsets are negative which means for GDAL that they are north to the top left pixel, thus totally outside the image area. QGIS is using negative offset natively in the top-down direction but it usually turns the sign correctly for the GDAL commands. However, I noticed that if original image is already georeferenced the QGIS behaves all wrong - it takes georeferenced coordinates from the source and not pixels/lines.
    – user30184
    Oct 11, 2014 at 10:41

3 Answers 3

Reset to default
2

Assuming you have saved the output of your GCP points, can you compare the values in this file with the auto-generated script? I've noticed that the script rounds values; I wonder if this could be introducing a source of error.

Improve this answer
1
  • The script does indeed round the values, but it rounds to the nearest hundredth, so the rounded values are very close of those of the saved file. Just in case, I swapped in the original points, but there was not a change. Thank you for the suggestion though!
    – Chris S.
    Oct 10, 2014 at 15:27
1

I have encountered this problem recently as well so I checked the pixel coordinate system used by the QGIS Georeferencer and noticed that the origin (upper left corner) is at (1000, 1000) instead of (0, 0).

You might want to check if your origin is not (0, 0) and apply necessary offsets to the pixel coordinates and see if gives you the right output (it worked for me).

Improve this answer
0

The comment by @user30184 indicates the problem. The manual shows that the arguments to gcp are "pixel line easting northing elevation". For the qgis generated gdal script to be correct, you must have loaded a raster without a reference system. Otherwise the first two arguments for each -gcp will be wrong.

I removed the spatial information from my tif with this:

gdal_translate -co PROFILE=BASELINE in.tif out.tif

Then I loaded out.tif and found the ground control points using qgis and exported the script.

Alternatively you could convert the first two arguments of each of your existing gcps to the pixel and line of the image.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.