[Proj] SRS stuff broken in GDAL and PROJ
tutey at o2.pl
Thu Apr 24 03:48:36 EDT 2008
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.:
>> <4009> +proj=longlat +a=6378450.047548896 +b=6356826.621488444
>> +no_defs <>
>> <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.
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?
More information about the Proj