I have a number of 1 km hexagonal grids that cover various counties in the United States in a postgreSQL/postGIS database. Each grid has the CRS EPSG:3857, and the counties layer has EPSG:3857. When viewing the grids with the counties in QGIS, everything looks grand.

But ... in order to share these grids with colleagues, I've had to export them to shapefiles using ogr2ogr. Viewing these in QGIS, each grid looks nudged up about 20 km or so, and QGIS automatically sets the CRS to EPSG:3395 (which is not the project CRS).

When I export the postGIS tables as shapefiles from QGIS, the .prj file looks exactly the same as the ogr2ogr exported shapefiles, but the postGIS exported tables are displayed correctly. I noticed that QGIS creates a .qpj file when exporting shapefiles from QGIS, so I've come to the conclusion that QGIS is ignoring the .prj and looking for a .qpj instead. Why can't it read the .prj without a .qpj? Other shapefiles (such as those from the US Census) don't have a .qpj but QGIS displays these correctly.

I've come up with a workaround by saving a default.qpj and creating a new .qpj from this for every file that export using ogr2ogr, but this seems messy and obviously not reproducible as it only works for EPSG:3857.

Sidenote: I'm using QGIS 2.0.1.


Here's the ogr2ogr command I used:

ogr2ogr -f "ESRI Shapefile" /home/matt/data/hex_grid_1 PG:'dbname=mydb user=matt' hex_grid_1

Contents of the .prj:


Contents of the .qpj:

PROJCS["WGS 84 / Pseudo-Mercator",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]],PROJECTION["Mercator_1SP"],PARAMETER["central_meridian",0],PARAMETER["scale_factor",1],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["X",EAST],AXIS["Y",NORTH],EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs"],AUTHORITY["EPSG","3857"]]


The problem was solved by converting the EPSG:3857's to EPSG:2163 in all my scripts. I'm still not sure what the problem is though since the grids displayed correctly in QGIS when originally loaded from a postgreSQL table (with EPSG:3857).

My workaround proved crude as I thought it did, since my colleague was unable to use the file in ArcGIS, which didn't read the .prj or the .qpj properly.

  • Can you add the ogr2ogr command? Mar 9, 2016 at 0:14
  • Can you also post the contents of both the .prj and .qpj files?
    – mkennedy
    Mar 9, 2016 at 0:30
  • 1
    May be there are limited capabilities on that "WGS84 Web Mercator Projection on a Auxiliary Sphere" en.wikipedia.org/wiki/Web_Mercator ..Unlike the ellipsoidal Mercator and spherical Mercator, the Web Mercator is not quite conformal due to its use of ellipsoidal datum geographical coordinates against a spherical projection.
    – huckfinn
    Mar 9, 2016 at 5:20
  • @huckfinn I changed all the EPSG:3857's to EPSG:2163's in my script and my problem is now solved. I'm still not sure why this is though since the grids all displayed correctly when loaded from the postgreSQL tables with EPSG:3857. Thanks for the tip.
    – haff
    Mar 9, 2016 at 23:41

1 Answer 1


The EPSG:3857 definition is a dirty hack to get the projection that Google invented into modern GIS software. It's a combination of sphere and ellipsoid that is not used by "normal" projections. Unfortuantely, every software uses another way to adapt it.

QGIS uses the .qpj file, ARCGIS the WKT in the .prj file and GDAL the proj.4 definition. The .qpj file incorporates the proj.4 definition into the WKT definition.

The safest way to deal with such problems is to avoid Google Mercator. You can better use your local State Plane, UTM or some continent-wide Lambert or Albers projections.

  • Good to know. Thanks for your answer. I've noticed however that when I export a shape file with EPSG 2163 using ogr2ogr, there is no .qpj created, yet QGIS still reads it properly. So I'm assuming that QGIS will read info from a .prj in the absence of a .qpj. Also, state plane projections will work great if operating just in one state, but my scripts take county fips codes from many states, so a state plane would not be practical in my case.
    – haff
    Mar 10, 2016 at 22:32
  • 1
    QGIS usually works ok with the .prj file, but not with World Merctaor projected files that come from other software. The best suited CRS is always dependent on the size of the study area. EPSG 2163 should be ok for your task.
    – AndreJ
    Mar 11, 2016 at 6:29

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.