[osgeo4w-dev] [osgeo4w] #320: Transformation Problem with Merchich Sahara Projections

OSGeo4W trac_osgeo4w at osgeo.org
Fri Nov 30 16:21:27 PST 2012

#320: Transformation Problem with Merchich Sahara Projections
Reporter:  ysid    |       Owner:  osgeo4w-dev@…              
    Type:  defect  |      Status:  new                        
Priority:  major   |   Component:  Package                    
 Version:          |    Keywords:                             
 When using cs2cs to transform into a Merchich Sahara projection (EPSG
 26194 or 26195) in OSGeo4W v1.9.1, results can be incorrect.  Results are
 correct when no GDAL/PROJ/OSGeo variables are specified in the
 environment, but are incorrect when specified.  To be clear, I will
 present an example:

 Input coordinate:
  * Projection: Geographic WGS84 (EPSG 4326)
  * Proj4: +proj=longlat +datum=WGS84 +pm=greenwich +ellps=WGS84
  * Coordinate: -16.6666666666667 18.6666666666667

 Output coordinate:
  * Projection: Merchich Sahara South (EPSG 26195)
  * Proj4: +proj=lcc +units=m +towgs84=31,146,47,0,0,0,0 +pm=greenwich
 +a=6378249.2 +b=6356515 +lon_0=-5.4 +x_0=1500000 +y_0=400000 +lat_0=22.5
 +lat_1=22.5 +k_0=0.999616437
  * Coordinate: 310159.282196 20443.0660249

 Note: Instead of the "+b" value, an alternative "+rf" variable can be
 specified, and will give results that are virtually identical (rf value is

 The abovementioned coordinate is the correct value, as verified by the


 Similar results are also obtained in PCI and ArcGIS.

 When running the above transformation using cs2cs, the following command
 is used:

   cs2cs.exe -f "%.03f%" +proj=longlat +datum=WGS84 +pm=greenwich
 +ellps=WGS84 +to +proj=lcc +units=m +towgs84=31,146,47,0,0,0,0
 +pm=greenwich +a=6378249.2 +rf=293.466021293627 +lon_0=-5.4 +x_0=1500000
 +y_0=400000 +lat_0=22.5 +lat_1=22.5 +k_0=0.999616437 input.txt >

 The result depends on the environment setting.  When no environment
 setting specific to PROJ4 or GDAL are set, the results are correct.
 However, when environment variables are set, the result is very wrong.

  * Without environment settings: 310159.282 20443.066 -80.008
  * With environment settings: 296432.545 39220.367 -80.008

 Interestingly, the ellipsoidal height is the same in both cases.

 Environment settings used are typical for an OSGeo4W/GDAL installation, as

 GDAL_DATA: <OSGeo4W_install_dir>\share\gdal
 GDAL_DRIVER_PATH: <OSGeo4W_install_dir>\bin\gdalplugins\1.9
 GEOTIFF_CSV: <OSGeo4W_install_dir>\share\gdal
 OSGEO4W_ROOT: <OSGeo4W_install_dir>
 PROJ_LIB: <OSGeo4W_install_dir>\share\proj

 Strange results are also seen when using gdalwarp with the same from and
 to projections and environment variables.

 Something in the OSGeo4W installation is causing the coordinates to be
 transformed incorrectly.

Ticket URL: <http://trac.osgeo.org/osgeo4w/ticket/320>
OSGeo4W <http://trac.osgeo.org/osgeo4w>
OSGeo4W is the Windows installer and package environment for the OSGeo stack.

More information about the osgeo4w-dev mailing list