[Proj] Re: SRS stuff broken in GDAL and PROJ

[Maciej Sieczka]

As the attachments were too big for the ML I'm re-sending the message
with the list of control points and script attached only.

Frank Warmerdam pisze:
> Maciej Sieczka wrote:

>> Ouch. So SRS stuff is pretty much broken in GDAL and PROJ. I 
>> subscribed to the ticket and I'd be happy to help with testing.

> I disagree with the assessment that things are broken.  They are just
>  a little bent. Numerically the differences are insignificant.

Frank,

So I checked and it looks that, unfortunately, things really are broken.

I have compared the results of re-projection from ll/WGS84 to each EPSG
code common for PROJ 4.5 and 4.6, using proj4 strings as present in the
"epsg" file.

Test points were obtained from the EPSG dataset v6.15 [1] using 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
epsg_coordinatereferencesystem.deprecated=0;

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.zip.

The "epsg" files were extracted from PROJ.4 4.5 and 4.6 source code, and
named "epsg.45", "epsg.46", respectively.

These files were used as an input for the attached script,
proj-epsg_45vs46.sh. It's output are 2 files: epsg.45.result,
epsg.46.result. When comparing them it is clear that there are
numerically significant differences between epsg files coming with
PROJ.4 4.5 and 4.6.

Out of the 2865 common EPSG codes, proj4 strings of 133 of them are
different enough between the epsg files of PROJ 4.5 and 4.6 to result in
re-projection errors of few centimeters most of the time, about a meter
in several cases to as much as kilometers in few. I would call this a
critical issue.

> The issue is with comparing string representations of coordinate 
> systems.

That's another big issue.

Maciek

[1]http://www.epsg.org/databases/Discv6_15sql-PosgreSql.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: epsg_control_pts.txt.zip
Type: application/zip
Size: 18576 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20080505/7432e406/attachment.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proj-epsg_45vs46.sh
Type: application/x-sh
Size: 896 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20080505/7432e406/attachment.sh>