[GRASS-dev] Location wizard (missed window to select +towgs params)

[Paul Kelly]

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 at gmail.com> 
>> wrote:
>>> Hi,
>>> 
>>> 2010/3/12 Massimo Di Stefano <massimodisasha at 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