[Proj] SRS stuff broken in GDAL and PROJ

[Maciej Sieczka]

Frank Warmerdam pisze:
> Maciej Sieczka wrote:

>> 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  <>

> 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

Ouch. So SRS stuff is pretty much broken in GDAL and PROJ. I subscribed 
to the ticket and I'd be happy to help with testing.

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

Please do. Can you say what is the latest safe GDAL version? As for PROJ 
- is it necessary to revert to 4.5.0 or is copying the epsg file from 
4.5.0 to 4.6.0 installation enough?

> 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.

If that's not too much offtopic, can you explain why GDAL/OGR supports 
non-C locale numbers in SRS stuff? I never saw an SRS definition with 
comma instead of dot as a decimal separator (though I've been living in 
a non-C country). Are they common?

Maciek