I'm wrestling with a problem that I am sure I've created for myself, but cannot resolve.
I received a set of shapefiles that were expressed with UTM, and I want them to use lat/lon. QGIS will do the translation, of course, but there are hundreds of files and I didn't want to do this manually.
So I obtained the code for converting the UTM (N, Zone 14) to lat/lon and re-wrote the .shp files, taking care to change the bounding box values in the main header, the bounding box values in the record headers, and all the point values (these are polygons).
I replaced the .prj file with this, which reflects the constants I used in the conversion:

GEOGCS["GCS_North_American_1983",   DATUM["D_North_American_1983",    SPHEROID["GRS_1980",6378137,298.257222101]],    PRIMEM["Greenwich",0],    UNIT["Degree",0.0174532925199433]]

Yet QGIS treats the file as if it's UTM -- it displays nothing on the screen, and the cursor position is expressed as easting/northing.

If I look at the layer properties, in the Metadata tab it shows this:

In layer spatial reference system units : xMin,yMin 677384.09,4068257.57 : xMax,yMax   732884.09,4351757.57
Layer Spatial Reference System:
+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs

Am I correct that there appears to be dissonance between the min/max units and the projection?

I cannot find anything that is telling QGIS to display this using UTM, but obviously,
I'm overlooking something.
GlobalMapper displays the file without complaint.

Any thoughts on what I'm overlooking?


  • 1
    You rewrote the Shapefile? Really? The binary .shp part? Please look into ogr2ogr for batch reprojecting.
    – underdark
    Commented Jun 4, 2013 at 21:00
  • Are there spatial index files? (.sbn/.sbx/.fbn/.fbx) They probably need deleted too.
    – mkennedy
    Commented Jun 4, 2013 at 22:43
  • Yes, I rewrote the shapefiles :) That was a good deal easier than the UTM -> latlon calculation. And the spatial index files -- yes, they are/were present, so I moved the core files (.shp/.shx/.dbf/.prj) to a new directory and tried it; no luck. I deleted the .prj so that I was prompted for a projection; still doesn't work.
    – user18827
    Commented Jun 5, 2013 at 13:59
  • Perhaps I didn't use the correct command line parameter (-t_srs EPSG:4326) but ogr2ogr didn't change the .shp values from UTM -> latlon. It did rewrite the index file, though, which helped me discover my problem.
    – user18827
    Commented Jun 6, 2013 at 13:29

1 Answer 1


In your "conversion", I do not see that you changed the coordinates of the polygon vertices successfully. The layer extent is still in UTM coordinates (metres instead of degrees).

For converting a lot of files, I would suggest batch processing with ogr2ogr. If you are on Windows, use the standalone GDAL package from gisinternals.com with the following batch.

It might be a good idea to add a specification for the input srs. Assuming that the original projection is UTM 14N /WGS84:

FOR %%F in (<oldpath>\*.shp) DO ogr2ogr -s_srs EPSG:32614 -t_srs EPSG:4326 <newpath>\%%~nxF %%F 
  • I didn't save the project, but looked for any .qpj files -- there are none in the directory where the shapefiles are (I'm assuming that is where they'd be kept). I also looked in the QGIS home directories, and couldn't find it. About the vertices -- I mistakenly referred to them as points, since that's the data type for each pair. Those have been converted to lat/lon. I did check the converted values (using the Corpson utility) to see if my own conversions of UTM -> latlon were correct, and they seem to be. It's as if QGIS is "remembering" the projection because I cannot find a trace of UTM...
    – user18827
    Commented Jun 5, 2013 at 14:05
  • 2
    OK, forget about the .qpj files. Looking at the quoted metadata, the projection is set to latlong, but the coordinates are not transformed to that. Give ogr2ogr a chance, it does those things easily and correct.
    – AndreJ
    Commented Jun 5, 2013 at 14:50
  • Andre, thanks for the advice; I'll get the Windows package and give it a try. I am still curious, though, where QGIS is getting derailed. Is there additional info I can put into the .prj file to prevent that?
    – user18827
    Commented Jun 5, 2013 at 15:16
  • 1
    It's not QGIS that went wrong, but the manual conversion of the shapefile. QGIS states that the layer is in latlong CRS, but the data is not.
    – AndreJ
    Commented Jun 5, 2013 at 15:27
  • Perhaps. So here's what I did: I opened the native (UTM) version, which displays properly, and used "Save As" in QGIS to create a latlon version, giving it a new name. I opened the latlon version to verify it was valid. I then copied the .shp/.shx/.dbf/.prj to another directory, and renamed the files to the old name. When I open this file I have the same UTC/latlon conflict. This is a file that involved no manual conversion, other than a name change. As I noted earlier, Globalmapper displays the manually converted file. So does ArcExplorer. Is there some config file that QGIS is consulting?
    – user18827
    Commented Jun 5, 2013 at 16:01

Your Answer

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

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