Hello,
I have found a case where gdaltransform and cs2cs don't give the same
results :
$ gdaltransform -s_srs +init=IGNF:MILLER -t_srs EPSG:4326
-20037504 10018752
179.798600354466 72.943850852954 12400.9953186931
$ cs2cs -f "%.11f" +init=IGNF:MILLER +to +init=epsg:4326
-20037504 10018752
-17
Selon Jean-Claude Repetto :
Jean-Claude,
I've investigated a bit. Here are my findings.
gdaltransform asks PROJ.4 to expand the SRS definition "+init=IGNF:MILLER" into
a full PROJ.4 string.
The lookup in the IGNF file results in :
+proj=mill +towgs84=0.,0.,0.,0.,0.,0.,0.
On 11-01-17 10:55 AM, Even Rouault wrote:
I get the same results as in the cs2cs command line.
I have no idea why we add +R_A when writting the PROJ.4 string of a Miller
projection. SVN history points to a commit that dates back to 10 years ago :
http://trac.osgeo.org/gdal/changeset/1862/trunk/o
On 01/17/11 18:40, Frank Warmerdam wrote:
A bit of digging shows that +R_A tells PROJ.4 to use a spherical radius
that
gives a sphere with the same surface area as the original ellipsoid. I
imagine I added this while trying to get the results to match PCI's GCTP
based implementation though the h
