Bug report #1037
srs.db incomptatible with GDAL >= 1.4.4
|Affected QGIS version:||Regression?:||No|
|Operating System:||All||Easy fix?:||No|
|Pull Request or Patch supplied:||Resolution:||fixed|
|Crashes QGIS or corrupts data:||Copied to github as #:||11097|
Since GDAL 1.4.4 there is a change r1,r2 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 r1 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 r3.
#4 Updated by Maciej Sieczka - almost 13 years ago
- Resolution set to fixed
- Status changed from Open to Closed
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.