I have a shapefile with the following .prj file:


When I run the following python code:

    srs = osr.SpatialReference()
    if ( srs.ImportFromWkt( prjText ) != 0 ):
        return "error"

    srsProj4 = srs.ExportToProj4()
    sourceProjection = pyproj.Proj( srsProj4, preserve_units=True )

the variable srsProj4, as returned from srs.ExportToProj4(), is an empty string.

When I look here: http://www.gdal.org/ogr/classOGRSpatialReference.html

it says that ExportToProj4() returns an empty string in the case the srs is in a local (non-geo-referenced) coordinate system. But as far as I understand, the text in the .prj file (above) is a valid, regular geo projection.

This code works with other .prj files I've used. Can you tell what's special about this one that's making it fail?


  • 1
    There is an error, but by default it is hidden, unless osr.UseExceptions(). The error is: RuntimeError: No translation for Albers to PROJ.4 format is known. This is possibly a bug.
    – Mike T
    Dec 7 '13 at 6:48
  • Mike Toews, thanks very much for the info. Very helpful.
    – M Katz
    Dec 7 '13 at 7:06
  • What version of gdal are you using? Is GDAL_DATA properly set?
    – user10353
    Dec 12 '13 at 18:09
  • Kyle, it's confusing to me. I am using GDAL 1.6, because my understanding is that's the latest one for which there are python bindings. In python I'm using osgeo, gdal, and pyproj, and I'm a bit confused as to which of those includes the others and which are independent. In any case, I have the path to the gdal binaries in "PATH", the path to the gdal data in "GDAL_DATA", and the path to the pyproj/projib set in "PROJ_LIB" -- all of those both as system environment variables and set via python's os.environ. All of this I've tried in various combinations always with the same error.
    – M Katz
    Dec 14 '13 at 4:00
  • Kyle (continued), I was somewhat encouraged when doing a comparison of, for instance, the alaska file inside of my GDAL/projlib folder with the alaska file in my python's pyproj/data folder. They are both binary files but the former has a different header, starting with "CTABLE V2.0" and then differing from the latter file in various places for the next 100 bytes or so, and then after that the contents are the same. The latter directory also has the file FL, whereas there is no such file in the former directory.
    – M Katz
    Dec 14 '13 at 4:04

It seems that osr has difficulties with PROJECTION["Albers"]. This could be a bug, and it is odd that gdalsrsinfo interprets, and corrects this to PROJECTION["Albers_Conic_Equal_Area"].

Here's the hackish fix:

from osgeo import osr

prjText = 'PROJCS["NAD_1927_Albers",GEOGCS["GCS_North_American_1927",DATUM["D_North_American_1927",SPHEROID["Clarke_1866",6378206.4,294.9786982]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Albers"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-96.0],PARAMETER["Standard_Parallel_1",29.5],PARAMETER["Standard_Parallel_2",45.5],PARAMETER["Latitude_Of_Origin",23.0],UNIT["Meter",1.0]]'

prjText = prjText.replace('"Albers"', '"Albers_Conic_Equal_Area"')
srs.ImportFromWkt(prjText)  # this will now raise RuntimeError for corrupt data
print(srs.ExportToProj4())  # another RuntimeError will be raised on failure

now shows:

+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs


gdalsrsinfo recognizes the definition, returning:

PROJ.4 : '+proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23 +lon_0=-96 +x_0=0 +y_0=0 +
datum=NAD27 +units=m +no_defs '


which should be equivalent to EPSG:5069 named NAD27 / Conus Albers

Maybe the name is not recognized correctly in Python.

  • Mike Toews seems to think it's more of an osr error than a python error?
    – M Katz
    Dec 8 '13 at 9:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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