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, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
