[gdal-dev] Failed to process SRS definition

[Even Rouault]

OGR only supports the "+a=xxxxx +b=yyyyy"  and "+a=xxxx +rf=zzzzz" 
combinations. It could be extended to support more combinations, but those 2 
ones are the most common to describe an ellipsoid. Patches welcome if your 
needs go beyond that.

I don't think OCTProj4Normalize() strips the b parameter. It's just, that OGR 
transforms (a, b) into equivalent (a, rf) in importFromWkt(), as the WKT 
modelling of an ellipsoid requires those later parameters.
And in exportToProj4() it will generate "+a=xxxx +b=yyyyy"

2 working examples :

1) testepsg "+proj=stere +lat_0=90 +lon_0=315 +lat_ts=70 +units=m +a=6378273 
+rf=278"

--> PROJ.4 rendering of [+proj=stere +lat_0=90 +lon_0=315 +lat_ts=70 +units=m 
+a=6378273 +rf=278] = +proj=stere +lat_0=90 +lat_ts=70 +lon_0=315 +k=1 +x_0=0 
+y_0=0 +a=6378273 +b=6355329.571942446 +units=m +no_defs

2) testepsg "+proj=stere +lat_0=90 +lon_0=315 +lat_ts=70 +units=m +a=6378273 
+b=6355329.571942446"

--> PROJ.4 rendering of [+proj=stere +lat_0=90 +lon_0=315 +lat_ts=70 +units=m 
+a=6378273 +b=6355329.571942446] = +proj=stere +lat_0=90 +lat_ts=70 
+lon_0=315 +k=1 +x_0=0 +y_0=0 +a=6378273 +b=6355329.571942446 +units=m 
+no_defs



Le Friday 17 July 2009 09:16:47 Jørn Vegard Røsnes, vous avez écrit :
> On Thursday 16 July 2009 20:59:55 Even Rouault wrote:
> > Le Thursday 16 July 2009 10:14:27 Jørn Vegard Røsnes, vous avez écrit :
> > > Hi again,
> > >
> > > On Wednesday 15 July 2009 13:12:38 Jørn Vegard Røsnes wrote:
> > > > Hi all,
> > > >
> > > > can you see the problem (this works with proj4)?
> > > > It works if I remove "+a=6378273" from proj4-string, but I assume the
> > > > output will be wrong.
> > > >
> > > > ./ogr2ogr -s_srs EPSG:4326 -t_srs "+proj=stere +lat_0=90 +lon_0=315
> > > > +lat_ts=70 +units=m +a=6378273 +e=0.081816153" -f "ESRI Shapefile"
> > > > gshhs_land_stere ~/download/gshhs_1.3_shapefiles/gshhs_land/
> > >
> > > I have downloaded v1.6.1, added some debug and compiled
> > > (--enable-debug).
> > >
> > > It seems that
> > >
> > > ogr/ogr_srs_proj4.cpp OGRSpatialReference::importFromProj4, line 847 -
> > > 945
> > >
> > > does not read the +e proj4 parameter (neither +f and +es), ref. page 9
> > > in proj4 doc (ftp://ftp.remotesensing.org/proj/OF90-284.pdf).
> > >
> > > +b and +rf is read by the code, so maybe there is a math. workaround?
> >
> > Yes, the a,b,e,f and rf parameters are tied by math relations.
> >
> > See http://www.arsitech.com/mapping/geodetic_datum. (rf is reverse
> > flattening = inverse flattening)
>
> Yes, I found
> http://en.wikipedia.org/wiki/Angular_eccentricity#Elliptic_parameters
> and calculated b, yesterday.
>
> Then I found something I do not know if is a feature or bug.
>
> ogr/ogrct.cpp OCTProj4Normalize
> strips away the b (, f and rf) parameter in the proj4 string. It is the
> call to  pszNewProj4Def = pfn_pj_get_def( psPJSource, 0 ); line 245
> that does this.
> I think this is a call to the proj4 libs and it seems that the proj4 libs
> removes the b parameter from the proj4 string, because proj4 is satisfied
> with the a and e params. OGR seems to require a and b, e is not used by
> OGR. I solved this by calling
> return CPLStrdup( pszProj4Src );
> in the start of the OCTProj4Normalize function.
>
> Note that I haven't downloaded the proj4 source, and I just assume in the
> text above.
>
> cheers
> Jørn Vegard
>
> > > cheers
> > > Jørn Vegard
> > >
> > > > All binaries (proj4, ogr2ogr) from FWTools 2.0.6
> > > >
> > > > cheers
> > > > Jørn Vegard
> > > > _______________________________________________
> > > > gdal-dev mailing list
> > > > gdal-dev at lists.osgeo.org
> > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > >
> > > _______________________________________________
> > > gdal-dev mailing list
> > > gdal-dev at lists.osgeo.org
> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev