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

Paul Kelly paul-grass at stjohnspoint.co.uk
Sun Mar 14 13:22:51 EDT 2010

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
However the location is being created with the parameters
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


More information about the grass-dev mailing list