[Proj] bugfix PROJ.4 release?
tutey at o2.pl
Tue Jul 1 15:21:47 EDT 2008
> Gerald I. Evenden pisze:
Clifford J Mugnier pisze:
>> How about a little reality check folks.
I can see these few decimal places in +k, +x_0, +y_0 parameters do make
a huge difference anyway. I identified 118 ESPG codes, which, due to the
issue , have a different representation in the epsg file in PROJ.4
4.5 and 4.6, *and* for which this difference results in coordinate
translation error of centimeters-decimeters. Is this really neglectable?
Test points were obtained from the EPSG dataset v6.15  with the
following SQL query on the SRS's area-of-use boundaries:
SELECT coord_ref_sys_code, area_west_bound_lon, area_south_bound_lat
FROM epsg_coordinatereferencesystem, epsg_area WHERE
This gave a list of points located in the SW corner of each SRS's area
of use. The list is attached as epsg_control_pts.txt.
The epsg files were extracted from PROJ.4 4.5 and 4.6 source code, and
named epsg.45, epsg.46, respectively.
The files were used as an input for the attached script,
proj-epsg_45vs46.sh. Its output is a self-explanatory csv file that one
can load into a spreadsheet or whatever and calculate the difference.
Most differences are none or smaller than 1 cm, some are huge but due to
a reason we don't care about here (a change in datum handling in GDAL,
which affected epsg_tr.py output used to generate the PROJ.4 epsg files)
and for some I can't calculate the difference easily (they are
un-projected CRSs and I don't know how to handle sexagimal numbers in a
Yet, in the end the difference for 118 remaining SRSs is greater than 1
cm with a maximum of 1.65 m. You can find this extract attached in an
All data mentioned available at .
More information about the Proj