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

[Michael Barton]

I'm continuing to follow this discussion and I don't think it will be a huge
problem to wrap this into TclTk. The simplest way for TclTk to parse this is
to simply have each datum transformation be a separate line in text sent to
stdout. 

1:dt1 parameters
2:dt2 parameters
3:dt3 parameters
...and so on

The way I'm thinking of doing this is to open a read channel from the
command as follows...

set input [open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=-1"]
set dtrans [read $input]
close $input
if {$dtrans==""} {
    # I assume that $dtrans=="" if there is only one default parameter
    open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=0"
else {
    # do some kind of selection dialog here where the user
    # picks the desired datum transformation from the list in
    # dtrans and "set dtsel [integer of user datum trans selection]"
    open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=$dtsel"
}


Is this what you also have in mind???

Michael

On 2/12/07 10:26 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> 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
> 
> 

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton