srs.db incomptatible with GDAL >= 1.4.4

[msieczka]

Since GDAL 1.4.4 there is a change [1],[2] that the scale factor k is treated as numeric instead of string variable. This results in a following proj4 string for eg. EPSG 2180 in GDAL > 1.4.2:

+proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m +no_defs

Whereas in QGIS srs.db, and GDAL =< 1.4.2 the same EPSG code is represented with a slightly different proj4 string:

+proj=tmerc +lat_0=0 +lon_0=19 +k=0.999300 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m +no_defs

The difference in the number of zeros in k factor makes QGIS fail to recognize the SRS, if QGIS runs against GDAL 1.4.4 or later. I verified that with the latest QGIS SVN trunk and GDAL 1.4.2, 1.4.4, 1.5.1.

As can be seen in [1] any SRS that uses k is affected. According to the epsg file shipped with PROJ 4.5.0, this gives 1142 out of 6442 SRS definitions incompatible between QGIS and GDAL > 1.4.2 [3].

[1]​http://trac.osgeo.org/gdal/changeset/12625 [2]​http://trac.osgeo.org/gdal/ticket/1970 [3]grep '\+k=:digit:*\.:digit:*0 ' /usr/share/proj/epsg

[jef]

see also #1035

[hamish]

see also bug #1079

[hamish]

the real problem is not the extra 00s, it is trying to do exact string matching from two different sources of data and expect the result to be the same.

Removing those 00s only fixes one symptom in a greater problem, and only temporarily.

Hamish

[msieczka]

FWIW an udpated srs.db has been subbmitted to SVN and is going to be included in 0.11. The srs.db is compatible with GDAL >= 1.4.4. Although Hamish point is valid, this particular ticket belongs to a different subject. Please open a new ticket if necessary.

The script is available as an attachement in ticket #1035.

[(none)]

Milestone Version 1.0.0 deleted