[Qgis-developer] Re: srs.db epsg's added, shrinking?

[Maciej Sieczka]

Frank Warmerdam pisze:
> Maciej Sieczka wrote:
>> Tim Sutton pisze:
>>
>>> Gary and I originally loaded the srs.db using the postgis srs table.
>>> The idea was to try to synchronise regularly against postgis srs table

>> You mean the "tbl_srs", right? How were the "tbl_projection" and 
>> "tbl_ellipsoid" created?
>>
>> I'm trying to get srs.db/tbl_srs in sync with the spatial_ref_sys 
>> shipped with PostGIS 1.3.3 (should not be too hard) but I don't know 
>> what to do with the 2 other tables in srs.db.

> Well, if you are doing that, should I belay efforts to have the
> epsg_tr.py script generate stuff for the srs.db?  epsg_tr.py is
> used to generate the postgis spatial_ref_sys table.
> 
> I'm not so keen that I want to duplicate efforts.

Frank, All,

Before going on - I'm getting puzzled. Based on EPSG:2180:

PostGIS 1.3.3 (just released few days ago), their spatial_ref_sys table:
column 'proj4text column' : k = 0.999300
column 'srtext' : k = 0.9993

GDAL 1.5.0 + svn:
files pcs.csv, projop_wparm.csv, ecw_cs.wkt: k = 0.9993

PROJ 4.6.0, epsg file:
k = 0.9993000000000001

Shouldn't the number of zeros in '+k' be identical in all those software 
in all places for them to interact smoothly? And why does the PROJ have 
a bogus value? In 4.5.0 it was 0.999300.

I was going to trimm the spurios zeros from scale factor definitions in 
QGIS srs.db (so that we get rid of the incompatibility as described in 
this therad before [1]), but I'm now wondering whether fixing QGIS-GDAL 
interaction this way would eg. brake QGIS-PostGIS or something else instead?

Maciek

[1]http://www.nabble.com/forum/ViewPost.jtp?post=16592795&framed=y