[Proj] bugfix PROJ.4 release?

Maciej Sieczka 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.

> Ahem.

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 [1], 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 [2] 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
epsg_coordinatereferencesystem.area_of_use_code=epsg_area.area_code AND
epsg_coordinatereferencesystem.show_crs=1 AND

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
ODS file.

All data mentioned available at [3].



Maciej Sieczka

More information about the Proj mailing list