This is not correct, and indeed seems to be a clue as to
what is going on. The GRASS default parameters for
rome40/Monte_Mario are +towgs84=-225.000,-65.000,9.000
However the location is being created with the parameters
+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68
i.e. the parameters with the description "Used in Italy
(Peninsular Part)" from datumtransform.table.
This set of parameters is not being put there by GRASS; it
is coming through from GDAL when it is used to look up the
EPSG code.
...
This is true, and as there have been very minimal changes
in general/g.proj and lib/proj between RC5 and now I was
initially very baffled. My latest hunch is to do with the
CSV tables in lib/proj. I notice Markus has updated them at
least a couple of times since RC5 - the latest change two
weeks ago in r41248 with the description "backport from
GDAL: big upgrade to EPSG 7.4.1 with improved datum logic"
sounds particularly suspicious I would hazard a guess
that GDAL is now attempting to make a "best guess" at which
are the most appropriate transformation parameters for a
particular datum. Previously if there was a choice it left
them unspecified, and GRASS prompted the user. However GRASS
(i.e. g.proj) trusts the co-ordinate system it gets back
from GDAL and if the datum transformation parameters are
already there, then it doesn't query GDAL's decision! I
don't subscribe to the GDAL developers list any more as
there was too much traffic, so it's likely I've missed some
discussion or announcement from Frank over there.
I haven't had time to test reverting the CSV files yet but
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...
On Mon, Mar 15, 2010 at 8:44 AM, Hamish <hamish_b@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)
(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)
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.
[...]
"While this got rid of one family of errors, it also triggered lots of additional frustration and confusion. Part of this was just because there was a change of behavior. But it was also pushing people a bit harder to determine the appropriate datum shift and they did not like having to do this.
So, at last, I have taken the plunge and reworked the scripts used to translate the EPSG dictionary so that they attempt to pick one shift if there are several available. I follow a few heuristics in this effort."
[...]
In the past GRASS has sided with correctness over convinence
(aka save time in the long term vs. short term); I suggest we
figure out a way to stick with our old "show the user a list
of alternatives and make them choose (forcing them to look it
up or make some phone calls, if necessary)" method.
it may be a PITA but in the long term you are doing them a big
favour. Software which are primarily data-viewers may have other
priorities of course.
"Currently GDAL, and the PROJ.4 dictionary are just using the preferred datum shift. But the intention of keeping the datum_shift.csv file with all the possible shifts for any given GCS is that savvy applications could let the user choose."
so for future merging we'll have to be more savvy.
(I'm pretty happy with our internal dautm.table and
datumtransform.table to be honest)
until then, I guess we revert the .csv files, while checking
for intermingled bug fixes if possible.
"datum_shift_pref.csv" prefers the 7-term NZGD49 transform over
the 3-term. But that ignores the NTv2 file if present(??).
And often you are given data known to be in the "less desirable"
transform parms (still used by the vast majority of other
software) but documented numeric consistency is more important
that keeping up with the latest transform ideas.
On Mon, Mar 15, 2010 at 8:44 AM, Hamish <hamish_b@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.
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?
Of course it is a pity that CSV-sync'ing no longer works between
GDAL and GRASS.
I suppose so, but there has been a big change in the datum transform philosophy of GDAL and for the moment it is incompatible with GRASS. I would imagine keeping things as-is for 6.x, but for 7.x extending g.proj to also report the other possible datum transformations from the EPSG database (obtained via GDAL) as well as GRASS's own parameters from datum.table and datumtransform.table. I think it is necessary to keep the internal GRASS lists because (a) the descriptions as to validity seem to be more detailed than in the GDAL EPSG list - I need to check that for sure but for Monte_Mario at first glance they seemed to be, and (b) there is no support for gridshift-based transformations in the EPSG-derived list.
I would hazard a guess