[Qgis-developer] Re: srs.db epsg's added, shrinking?
tutey at o2.pl
Thu Apr 17 16:04:43 EDT 2008
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.
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 ), but I'm now wondering whether fixing QGIS-GDAL
interaction this way would eg. brake QGIS-PostGIS or something else instead?
More information about the Qgis-developer