[gdal-dev] Re: SetEquarectangular() changes

[Frank Warmerdam]

RICHARD Didier wrote:
>> 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.

Didier,

OK, but the changes are still inappropriate and have nothing to
do with Equirectangular.

>> Likewise many changes in nitfdataset.cpp.
>>
> 
> Same reason.

Ditto

>> 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 :

See:

http://trac.osgeo.org/gdal/changeset/15642#file14

For some reason massive amounts of stuff were removed, and the C++
definitions from ogr_spatialref.h got inserted.

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

I won't be snapping beta1 for several hours so if you can apply a gstmerc
change that would be good.  If there are changes required in libgeotiff we
will need to also look into that.  If you don't manage it tonight, it is
still ok to put them in before beta2.

Best regards,
-- 
---------------------------------------+--------------------------------------
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