Hello all,
I have a little more insight on this. See below.
On Fri, 12 Mar 2010, Paul Kelly wrote:
On Fri, 12 Mar 2010, Markus Neteler wrote:
On Fri, Mar 12, 2010 at 8:38 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2010/3/12 Massimo Di Stefano <massimodisasha@gmail.com>:
"location wizard -> select epsg code -> search for : 3004"
in the paste release (build less than 1 month ago) after select the epsg:code(3004)
grass prompt me to the window :
http://img534.imageshack.us/img534/8254/schermata20100312a09564.png
to select the +towgs parameters
with the latest svn version this window doesn't appair and the locaqtion is created using the default parameters :
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
...
it seems to be bug in g.proj -
g.proj epsg=3004 datum=-1
no output is printed...
When you add -t, it works:
g.proj epsg=3004 datum=-1 -t
The fact that the -t flag needs to be specified, suggests that somehow when g.proj is querying GDAL for a projection description for EPSG code 3004, it is coming back fully specified, i.e. with complete towgs84 parameters, and thus g.proj thinks the datum information is already all specified and correct, so it doesn't even offer the option of modifying it unless the user requests to override the datum information in the input co-ordinate system with the -t flag. (I'm sure there is a logical reason for working like that although it doesn't immediately come to mind at the minute!)
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...
More later
Paul
