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

[Maciej Sieczka]

Maciej Sieczka pisze:
> 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?

Hi

Sorry if I'm a pain, but as nobody replies I don't know what to think 
about the issue and how to proceed with srs.db update. Could someone 
(this probly means Frank who has best insight into SRS stuff of his 
software and software he contributes to) please take a closer look and 
tell me if there are problems to expect due to differences in 'k' 
parameter formatting in PROJ, GDAL, PostGIS and QGIS

Can I just trimm of the spurious zeros in all k parameters in srs.db or 
would that bring side effects in interaction of the mentioned software 
(propably add MapServer to the list, as QGIS can create MapServer map 
files)?

Moreover I'm affraid PROJ.4 4.6.0 uses wrong (AFAICT) values for many 
coordinate systems. Compare the PROJ.4's epsg file in version 4.5.0 and 
4.6.0, and see how parameters differ (in terms of real numbers, not only 
number of extra zeros) in many SRS definitions, eg. EPSG 26794-26798, 
2180, 2255-2262, 2057, 2000-2007 and more. Looks like some rounding 
errors (?). Eg.:

4.5.0:
<4009> +proj=longlat +a=6378450.047548896 +b=6356826.621488444 +no_defs <>

4.6.0:
<4009> +proj=longlat +a=6378450.047548897 +b=6356826.621488445 +no_defs  <>

4.5.0:
<2965> +proj=tmerc +lat_0=37.5 +lon_0=-85.66666666666667 +k=0.999967 
+x_0=99999.99989839978 +y_0=249999.9998983998 +ellps=GRS80 +datum=NAD83 
+to_meter=0.3048006096012192 +no_defs  <>

4.6.0:
<2965> +proj=tmerc +lat_0=37.5 +lon_0=-85.66666666666667 +k=0.999966667 
+x_0=99999.99989839978 +y_0=249999.9998983998 +ellps=GRS80 +datum=NAD83 
+to_meter=0.3048006096012192 +no_defs  <>

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

4.6.0:
<2180> +proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993000000000001 +x_0=500000 
+y_0=-5300000 +ellps=GRS80 +units=m +no_defs  <>

Maciek