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

Hamish hamish_nospam at yahoo.com
Tue Feb 13 03:56:18 EST 2007


Hamish:
> > 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?
Paul:
> 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 :)

Ok, the only thing I'd add is that we should remember the proj4=
exists for corner cases. I suppose now we have the minimum simple
AND correct solution? That is the hope anyway.

H:
> > 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.
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.

H:
> > outstanding issue: allow these datumtrans= word aliases?
> > list => -1
> > none => 0
> > default => 1
P:
> We could, yes. We are not really gaining a lot to rely on the parser
> to validate the numbers I think.

One of the most important things the parser brings is protection from
buffer overflows from the command line. Obviously GRASS isn't anywhere
near free from that danger, but the parser goes a long way to covering
one wide open flank.

Paul:
> 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'm pretty sure I'll be able to digest that all come morning.

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

looks good so far, enjoy yourself!


minor cosmetics:

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.


cheers,
Hamish




More information about the grass-dev mailing list