My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 20: pyproj silently changes '+units=' parameter
1 person starred this issue and may be notified of changes. Back to list
Status:  New
Owner:  ----

Sign in to add a comment
Reported by, Mar 14, 2010
What steps will reproduce the problem?
1. Create a projection that is normally defined using feet by specifying
epsg code or proj parameters, e.g.,
pyproj.Proj(pyproj.Proj("+proj=lcc +lat_1=38.03333333333333 +lat_2=39.2
+lat_0=37.66666666666666 +lon_0=-78.5 +x_0=609601.2192024384 +y_0=0
+ellps=clrk66 +datum=NAD27 +units=us-ft +no_defs"))
2. Project a long/lat point

What is the expected output? What do you see instead?
Proj and OGR (which uses Proj anyway I suppose) both return the result in
the normal projection units (feet) but pyproj returns the result in metres
(as the documentation notes). It would be nice if pyproj followed the same
behavior as Proj or had a method to notify that the projection normally
uses feet as units.

What version of the product are you using? On what operating system?
Pyproj 1.8.7 (build 171) on Windows Vista

Please provide any additional information below.

At first I thought no problem, just multiply the pyproj value by
3.28083333333333 to get feet. The problem is knowing when to do this. If
the program using pyproj doesn't know much about projections (i.e., just
passes an epsg code string) then it would have to parse the epsg file to
find the projection definition and check to see if '+units=us-ft' is
defined to know when to apply the foot conversion. pyproj silently replaces
the '+units=us-ft' parameter with '+units=m'; it might make more sense to
have pyproj either return feet like proj or have a method to report if the
projection usually uses feet so the program utilizing pyproj can convert
the result.



Proj output
C:\Temp\repro>proj +proj=lcc +lat_1=38.03333333333333 +lat_2=39.2
+lat_0=37.66666666666666 +lon_0=-78.5 +x_0=609601.2192024384 +y_0=0
+ellps=clrk66 +datum=NAD27 +units=us-ft +no_defs
-114.057222 51.045
-6181891.74     6519223.10

pyproj output
>>> import pyproj
>>> wgs84_proj = pyproj.Proj(init="epsg:4326")
>>> foot_params_proj = pyproj.Proj("+proj=lcc +lat_1=38.03333333333333
+lat_2=39.2 +lat_0=37.66666666666666 +lon_0=-78.5 +x_0=609601.2192024384
+y_0=0 +ellps=clrk66 +datum=NAD27 +units=us-ft +no_defs")
>>> pyproj.transform(wgs84_proj, foot_params_proj, -114.057222, 51.045)
(-1884180.7611387274, 1987030.3180990468)

Mar 15, 2010
Project Member #1
I thought it would be better for pyproj to always return the same units.  As you point 
out, some epsg codes contain projections defined in us feet, and pyproj will convert to 
meters.  I see your problem, but I don't see any obvious solution that won't break other 
applications.  I guess one way would be too add a keyword arg to Proj, something like 
"preserve_units" that would turn off the automatic conversion to meters.  Would that 
work for you?
Mar 15, 2010
I see your point about always returning the same units for the sake of consistency;
it does make sense to always use metres. Normally this would work out well except for
those stored EPSG codes.

If a keyword arg like "preserve_units", that would turn off the automatic unit
conversion, could be added it would certainly do the trick for my purposes.
Mar 15, 2010
Tried out rev.172, the "preserve_units" keyword arg works great.


Proj output
C:\Temp>set PROJ_LIB=C:\Python26\lib\site-packages\pyproj\data
C:\Temp>proj +init=epsg:32046
-114.057222 51.045
-6181891.74     6519223.10

pyproj output
C:\Temp>set PROJ_LIB=C:\Python26\lib\site-packages\pyproj\data
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyproj
>>> pyproj.pyproj_datadir
>>> wgs84_proj = pyproj.Proj(init="epsg:4326")
>>> foot_proj = pyproj.Proj(init="epsg:32046", preserve_units=True)
>>> pyproj.transform(wgs84_proj, foot_proj, -114.057222, 51.045)
(-6181891.7357068071, 6519223.1006499557)

Sign in to add a comment

Powered by Google Project Hosting