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

[Frank Warmerdam]

Maciej Sieczka wrote:
> 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  <>

Maciej,

I believe these problems are due to a change in GDAL/OGR to use CPLAtof()
which gives slightly different results than atof() in some cases.

   http://trac.osgeo.org/gdal/ticket/2036

Perhaps you could work with Andrey on this problem and then I could
regenerate things.

BTW, we use a custom CPLAtof() so that coordinate systems with non "C"
locale numbers can be parsed, and so that "C" locale numbers can be
parsed in non "C" locales.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org