ogr2ogr fails when using PROJ.4 strings

[jcrepetto]

I have downloaded a shapefile of France (freely available from the IGN website at  http://www.ign.fr/telechargement/MPro/produit/GEOFLA_Dep/GEOFLA-dep-L2-SF.ZIP .
The shapefile contains data in tangent Lambert Conic Conformal projection, but I need geographical coordinates (longitudes, latitudes).

Since the projection and CS informations are not included in the original files, I have used the s_srs option to specify them (the tangent Lambert Conic Conformal projection (lcc1) and the NTF system).

When I use the EPSG code (27572), the result is correct :

ogr2ogr -f "ESRI Shapefile" -s_srs "EPSG:27572"  -t_srs "+proj=longlat +nodefs
+datum=WGS84" wgs dep_france_dom.shp

The coordinates of the first point of the original file are :
X=801150 Y=2092615

The result of the ogr2ogr command is :
4.924520108855378 45.804040002011874, which is correct.

Then I translate the EPSG code to PROJ.4 format:

$ epsg_tr.py -proj4 27572
# NTF (Paris) / Lambert zone II
<27572> +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.99987742 +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515 +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs  <>

and I type this command :

$ ogr2ogr -f "ESRI Shapefile" -s_srs "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.99987742 +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515 +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs"  -t_srs "+proj=longlat +nodefs
+datum=WGS84" wgs dep_france_dom.shp

Now, the result is :
7.261840271142879 45.804051007612635, which is wrong.

[warmerdam]

I have tried:

testepsg '+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.99987742 +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515 +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs'

and get back a PROJ.4 representation of:

 +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=2.3372291666985 +k_0=0.99987742 +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515 +towgs84=-168,-60,320,0,0,0,0 +pm=2.3372291666985 +units=m +no_defs

It appears the OGRSpatialReference PROJ.4 to WKT translation is mis-setting the central meridian (+lon_0) based on the prime meridian somehow.

I'll take this issue.

[warmerdam]

This was a bug in the OGRSpatialReference::importFromProj4(). It was applying the prime meridian offset to all central meridian and other longitudinal values. This was apparently something that predated "real" prime meridian tracking and ended up interfering with it. Garr.

I have removed it in trunk (r12535) and 1.4 branch (r12537) as well as added tests in gdalautotest/osr/osr_proj4.py (r12536).