[GRASS-dev] Location wizard (missed window to select +towgs
paul-grass at stjohnspoint.co.uk
Sun Mar 14 13:22:51 EDT 2010
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>
>>> 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
>>>> grass prompt me to the window :
>>>> 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)"
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 information about the grass-dev