On Mon, 15 Mar 2010, Markus Neteler wrote:
On Mon, Mar 15, 2010 at 8:44 AM, Hamish <hamis...@yahoo.com> wrote:
Paul wrote:
...
I haven't had time to test reverting the CSV files yet but
(I wonder how CSV files could mess up a logic but how knows...
Of course let's revert in 6.4 if this breaks things)
Hi Markus, After reading Frank's blog post (thanks for the link) I
understand - simply the CSV files now contain datum transform parameters
for all the datums that previously had no parameters specified because
there was a choice, and as Frank said he thought it best to force the user
to make a decision - this suited GRASS very well since as Hamish mentioned
the decision only needs to be made once, when setting up a new location,
and it is no trouble to take a few extra minutes to determine what is the
best choice.
(it also reminds me of my suggestion to leave all this business
to GDAL instead of having a potentially conflicting private
solution, but of course one can see it also the other way round)
Yes I definitely plan to do that in 7.x, but I note that the problem would
have been the same, except it would presumably have appeared more
noticeably after an upgrade to GDAL.
if that works I would suggest doing it, as if that is going
to be the way GDAL works from now on it will require quite a
few changes to how g.proj works, and it is much too late in
the release cycle of 6.4.0 to go changing things there...
Sure. Note: if so, it is the first time that CSV updates really break
the mechanism in GRASS.
hmmm +file lib/proj/datum_shift.csv
in https://trac.osgeo.org/grass/changeset/41248
see also r41223.
I can confirm that
svn merge -c -41248 .
fixes 6.4 release branch. Any opinions on whether we should also revert
r41223, or should I just commit the reversion now?
Paul
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
