A reader pointed out to me recently that that the pyshp documetnatin or wiki should include something about map projections. And he is right. Many programmers working with shapefiles are not necessarily geospatial professionals but have found themselves working with geodata on some project. It is very difficult to just ‘scratch the surface’ of GIS. You don’t have to dig very deep into this field before you uncover some of the eccentricities of geographic data. Map projections are one such feature that is easy to understand at a basic level but has huge implications for geospatial programmers. Map projections are conceptually straight-forward and intuitive. If you try to take any three-dimensional object and flatten it onto a plane, such as your screen or a sheet of paper, the object is distorted. (Remember the orange peel experiment from 7th grade geography?) You can manipulate this distortion to preserve common properties such as area, scale, bearing, distance, shape, etc. I won’t go into the details of map projections as there are thousands of web pages and online videos devoted to the subject. But there are some things you need to know for dealing with them programmatically. First of all, most geospatial data formats don’t even contain any information about map projections. This lack of metadata is really mostly just geospatial cultural history with some technical reasons. And furthermore, while the concept of map projections is easy to grasp, the math to transform a coordinate from one projection to another is quite complex. The end result is most data libraries don’t deal with projections in any way. But now, thanks to modern software and the Internet making data exchange easier and more common, nearly every data format, both images and vector, have tacked on a metadata format that defines the projection. For shapefiles this is the .prj projection file which follows the naming convention .prj In this file, if it exists, you will find a string defining the projection in a format called well-known text or WKT. And here’s a gotch that blew my mind as a programmer a long time ago: if you don’t have that projection definition, and you don’t know who created the data – there is no way you are ever going to figure it out. The coordinates in the file are just numbers and offer no clue to the projection. You don’t run into this problem much any more but it used to be quite common because GIS shops typically produced maps and not data. All your coworkers knew the preferred projection for your shop so nobody bothered to create a bunch of metadata. But now, modern GIS software won’t even let you load a shapefile into a map without forcing you to choose a projection if it’s not already defined. And that’s a good thing. If you do need to deal with projections programmatically you basically have one choice: the PROJ4 library. It is one of the few free libraries, if not the only library period, that comprehensively deals with re-projecting goespatial data. Fortunately it has bindings for just about every language out there and is incorporated into many libraries including OGR. There is a Python project called pyproj which provides python bindings. So be aware that projections are not trivial and can often add a lot of complexity to what would otherwise be a simple programming project. And also know that pyshp does nothing to work with map projections. I did an You provided us a good entry point with the important references to projection libraries. As geologist I am less concerned about how projections work, but which one to choose or how to deal with the nasty ones when confrontation is inevitable :) Thank you for the post. Source.