[Qgis-developer] Re: EPSG:2180 not recognised, although present in srs.db

[Maciej Sieczka]

Maciej Sieczka pisze:
> I built QGIS (latest SVN trunk) against an older PROJ 4.5.0 this time, 
> and GDAL 1.4.4. Still no good. Below is the relevant debug output when 
> loading the GeoTIFF. Looks like QGIS recognises the CS properly, but 
> then fails to find a matching one in srs.sb. Any ideas what is the reason?

I think I know what is going on. 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 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 is enough for QGIS to 
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.

Note that the problem is not limited to EPSG 2180. 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 1328 out of 6442 SRS definitions incompatible 
between QGIS and GDAL > 1.4.2 [3].

Quite an issue. Can anything be done about it? Just trim ending zeros of 
all k's in the srs.db? That would break comptibility between QGIS and 
GDAL < 1.4.4. Considering that 1.4.4 was released over 4 months ago 
maybe that would not be a big deal though?

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

Maciek