[gdal-dev] Re: SetEquarectangular() changes

[RICHARD Didier]

> Didier,
>

Frank,

> I've backed out r15642 (in r15643) for the time being because I suspect it
> included some unrelated changes that were inadvertant.
>
>    http://trac.osgeo.org/gdal/changeset/15642
>
> For instance some of the changes to geo_normalize.c and geo_ctrans.inc
> which
> really need to start out upstream in libgeotiff.

You're right, you wrote you a mail in between saying that the ticket
numbering in the commit's log was wrong : 2507 is to be replaced by
2478...

>  Also, the UOMLengthInMeters
> changes in gt_wkt_srs.cpp seem unrelated to the stated reason for the
> commit.

Same reason.

> Likewise many changes in nitfdataset.cpp.
>

Same reason.

> There also seems to be substantial alterations to ogr_srs_api.h  that I
> don't
> really understand.
>

ogr_srs_api.h : I don't understand too as my local file diff with the
reverted trunk is as follows :

--- /data/svn/GDAL/ogr/ogr_srs_api.h    2008-10-29 22:49:05.000000000 +0100
+++ ogr/ogr_srs_api.h   2008-10-29 10:58:20.000000000 +0100
@@ -1,5 +1,5 @@
 /******************************************************************************
- * $Id: ogr_srs_api.h 15643 2008-10-29 21:18:47Z warmerdam $
+ * $Id: ogr_srs_api.h 15280 2008-09-01 14:52:56Z dron $
  *
  * Project:  OpenGIS Simple Features Reference Implementation
  * Purpose:  C API and constant declarations for OGR Spatial References.
@@ -107,8 +107,8 @@
 #define SRS_PT_EQUIRECTANGULAR  "Equirectangular"
 #define SRS_PT_GALL_STEREOGRAPHIC                                       \
                                 "Gall_Stereographic"
-#define SRS_PT_GAUSSLABORDEREUNION                                      \
-                                "Gauss_Laborde_Sphere_Geometric_Mean"
+#define SRS_PT_GAUSSSCHREIBERTMERCATOR                                   
  \
+                                "Gauss_Schreiber_Transverse_Mercator"
 #define SRS_PT_GEOSTATIONARY_SATELLITE                                  \
                                 "Geostationary_Satellite"
 #define SRS_PT_GOODE_HOMOLOSINE "Goode_Homolosine"
@@ -429,9 +429,9 @@
 /** Equirectangular generalized form */
 OGRErr CPL_DLL OSRSetEquirectangular2( OGRSpatialReferenceH hSRS,
                               double dfCenterLat, double dfCenterLong,
-                              double dfPseudoStdParallel1,
                               double dfFalseEasting,
-                              double dfFalseNorthing );
+                              double dfFalseNorthing,
+                              double dfPseudoStdParallel1  /* = 0.0 */);

 /** Gall Stereograpic */
 OGRErr CPL_DLL OSRSetGS( OGRSpatialReferenceH hSRS, double
dfCentralMeridian,
@@ -446,8 +446,8 @@
                            double dfCentralMeridian, double
dfSatelliteHeight,
                            double dfFalseEasting, double dfFalseNorthing );

-/** Gauss Laborde Reunion */
-OGRErr CPL_DLL OSRSetGaussLabordeReunion( OGRSpatialReferenceH hSRS,
+/** Gauss Schreiber Transverse Mercator */
+OGRErr CPL_DLL OSRSetGaussSchreiberTMercator( OGRSpatialReferenceH hSRS,
                                   double dfCenterLat, double dfCenterLong,
                                   double dfScale,
                                   double dfFalseEasting,

something wrong happend ?

> The core reason for the change seemed to be to replace use of
> SetEquirectangular() with calls to SetEquirectangular2() with the first
> argument being zero.  I'm not sure this is a great idea.  Can we not leave
> SetEquirectangular and just have it call SetEquirectangular2() with the
> first
> argument as 0.0?  This would minimize changes, and leave the API so that
> private plugins won't be broken.  Generally speaking, I'm not keen on
> changing
> existing parts of the C++ API when easily avoidable as it seems to be in
> this case.
>

The core reason was two fold :
- reply to ticket 2478 as you mentionned above with SetEquirectangular()
and SetEquirectangular2();
- make GDAL / PROJ.4.6.1 compatible (gstmerc changes)

> I'd appreciate it if you could review the changes you want to make and
> apply
> them more narrowly.  I find commits from root can be pretty dangerous!
>

When I first proposed SetEquirectangular2() the purpose was to keep the
API similar as you mentionned. The ticket 2478 drove me in the wrong
direction in trying to merge to two SetEquirectangular*() methods.

As my first objective was to use GDAL 1.6.0 / PROJ4.6.1, I will only focus
on the gstmerc changes (hopping I have enough time as the deadline is
today --I mean wednesday-- for 1.6.0).

Sorry Frank and devs for the inconvenience,

> Best regards,

Sincerely,

didier
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
>


-- 
RICHARD Didier - Chef du pôle technique du Géoportail
2/4, avenue Pasteur - 94165 Saint Mandé Cedex
Tél : +33 (0) 1 43 98 83 23