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

[Paul Kelly]

Hello Hamish

On Mon, 12 Feb 2007, Hamish wrote:

> ok, so how about:
>
> datumtrans=-1   # write the list (including a "none" option) and exit
> datumtrans=0    # no datum specified
> datumtrans=1    # default
> datumtrans=2,.. # add'l options
>
>
> datumtrans=1 remains the default, but if multiple options exist, load
> the picker. Or do we always want to open the picker to allow ="none",
> even when there is only one option?

If there is only one, normally the parameters aren't specifically 
specifed. If they are for some reason, I've added a "force" flag (-t, for 
force setting Transformation parameters :/) that can be used to update the 
parameters even if they are already complete. E.g. you can use
g.proj -ct datumtrans=0 to remove specified parameters from the PROJ_INFO 
and in future the default will be used. So that was clear thinking on the 
0 = unspecified :)

> So after it gets a EPSG code it creates a new loc'n in two passes. The
> first time it runs with datumtrans=-1 to get the list, and the second it
> runs with the user specified answer. If the only option is "none" (eg
> epsg already specifies +towgs84=, as with NZTM <2193>) it skips the
> second pass (GUI picker) and directly creates the loc'n.

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.

>> Also, I was wondering what format would be appropriate for the
>> GUI-parsable list of datum transformation parameters. In the copy I
>> have I'm just printing to stdout the list that you got by typing list
>> at the old interactive prompt. Are there any existing examples of
>> something similar I wonder.
>
> The GUI needs to be able to transform it into a radio button list
> somehow. I guess it could just search for the existing "^---$" text
> to separate entries and re-use the existing formatting of the
> individual entries. Also it would be nice if it could pre-select the

I edited it a little bit to make it hopefully more parser-friendly - one 
item of info per line and no tabs at the start.

> default option when the GUI picker is opened.
>
> If it must be broken up into fields, "|" doesn't appear in the epsg
> file, lib/gis/datum.table, nor lib/gis/datumtransform.table so could be
> used as a field separator. It would be nice for the list to be human-
> readable if called from the command line. Or is the current output
> structured enough to rely on '^---$' and '\n' for that?

Yes it's still human readable.

> Will the default always be what's in "datum.table"? ie the default is
> always the 3-term +towgs84=dx,dy,dz parms?

If there is one, yes. If dx=dy=dz=9999 then the first entry for the datum 
in datumtransform.table will be the default.

> outstanding issue: allow these datumtrans= word aliases?
> list => -1
> none => 0
> default => 1

We could, yes. We are not really gaining a lot to rely on the parser to 
validate the numbers I think.

> # bonus:
> three_term => a
> seven_term => b

Very hard. It's currently abstracted to be just a "PROJ-4 compatible set 
of parameters" and doesn't really look at what's inside them anywhere.

Anyway, here's the description of the new functionality from the man page:

If the input co-ordinate system contains a datum name but no 
transformation parameters, and there is more than one suitable parameter 
set available (according to the files datum.table and datumtransform.table 
in ${GISBASE}/etc), g.proj will check the value of the datumtrans option 
and act according to the following:
-1: List available parameter sets in a GUI-parsable (but also 
human-readable) format and exit.
0 (default): Continue without specifying parameters - if used when 
creating a location, other GRASS modules will use the "default" (likely 
non-optimum) parameters for this datum if necessary in the future.
Any other number less than or equal to the number of parameter sets 
available for this datum: Choose this parameter set and add it to the 
co-ordinate system description.
If the module is being used from the command-line through an interactive 
terminal, the -i flag can be specified to enable interactive selection of 
the parameter set, and the value of datumtrans (if specified) is ignored.
If the -t flag is specified, the module will attempt to change the datum 
transformation parameters using one of the above two methods even if a 
valid parameter set is already specified in the input co-ordinate system.

I may not have time to get back to this for a few days as will be 
travelling a bit, but might do anyway.

Paul