[GRASS-dev] g.proj to create a new location

[Paul Kelly]

Hello Hamish
Been thinking a bit more about this. (Sorry for my silence on most stuff; 
have had really sporadic internet access for the last week...)

On Tue, 13 Feb 2007, Hamish wrote:

> P:
>> Yes. With datumtrans=-1 the location will get created straight away if
>> there is only one parameter set to choose from (unless you use the
>> force flag). The GUI could watch the output of g.proj and if it
>> specifed the list then go through it for the second pass.
>
> ? The -1 "list" option should only list and exit. Not sometimes work,
> sometimes not. My hope was that the GUI could see there were no options
> and skip the param picker dialoge and move right on to the -c creation
> step. ie datumtrans=-1 should ignore -c, otherwise it is trying to be
> two orthogonal modes at the same time.

My thinking in implementing the datumtrans and -i options has to be to do 
it as generally as possible, i.e. not with the case of creating a new 
location (from the GUI or otherwise) specifically in mind.

The way it is programmed now is that the value of datumtrans is checked if 
and only if the input co-ordinate system contains partial/ambiguous datum 
information (unless -t flag is used). If (datumtrans == -1) was always to 
be checked in any case, then if the input projection doesn't contain any 
datum info at all the behaviour would technically be undefined IMO. Would 
that have to be programmed in as a special case? I think the current 
behaviour is logical, though agree it is questionable and that it's 
possible I could come to look at differently and change my mind.

[...]
> G63> g.proj -c loc=tmp_test13v2 epsg=27200 datumtrans=2
> A datum name nzgd49 (New_Zealand_Geodetic_Datum_1949) was specified
> without transformation parameters.
> WARNING: Non-interactive mode: the GRASS default for nzgd49 is
>         towgs84=54.400,-20.100,183.100.
>
> "A datum name %s (%s) was specified without transformation parameters."
> is wrong.
>
> Also, as datumtrans= was set >0, the "Warning: default is:" is just
> noise and should be skipped. We don't care what the default is if
> we explicitly stated a real parm.

This comes from the library function. I haven't touched it at all and it 
needs tidied up. Probably remove the interactive flag as Glynn has 
suggested. Or even allow it to accept a number to indicate which datum 
parameters to use directly. That might be useful actually. r.in.gdal and 
v.in.ogr also use the library function so their behaviour needs to be 
considered too.

Paul