Ticket #1940 (closed defect: fixed)

Opened 10 months ago

Last modified 10 months ago

ogr2ogr fails when using PROJ.4 strings

Reported by: jcrepetto Assigned to: warmerdam
Priority: normal Milestone: 1.4.3
Component: OGR_SRS Version: unspecified
Severity: major Keywords: prime meridian
Cc:

Description

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.

Change History

10/25/07 09:27:02 changed by warmerdam

  • keywords set to prime meridian.
  • status changed from new to assigned.
  • component changed from default to OGR_SRS.
  • milestone set to 1.4.3.

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.

10/25/07 23:17:41 changed by warmerdam

  • status changed from assigned to closed.
  • resolution set to fixed.

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