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

[Hamish]

> Hamish wrote:
> > I have now added new epsg= and datumtrans= options to g.proj in CVS.
..
> > If it needs more info WRT datum transform options, it currently goes
> > interactive as the datumtrans= option to list or select datum
> > transform parms is not yet functional. Paul, can you try and connect
> > this to get_datum_transform_by_name() and GPJ_ask_datum_params(), or
> > wherever the number needs to get to? Mucho gracias.

Paul wrote:
> I have this working now in my local copy,

Great.

> but just realised a slight flaw with it. Because we are assuming a
> default of datumtrans=1, there is no way to assume if the user
> specifically asked for the 1st set of datum transformation parameters,
> or they are just using the default. Up to now, if the user didn't
> specifically specify datum transformation parameters, they were not
> written into the PROJ_INFO, only the datum name.

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?

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.

> When necessary then (e.g. using one of the re-projection modules), the
> current default parameters for that datum would be read from the
> datum.table file and used. So if the default changed (e.g. we
> discovered it was wrong and updated it) the user wouldn't need to edit
> their location to take advantage of the update. But if the parameters
> are written into the PROJ_INFO, then whatever default was in force at
> the time becomes set in stone.

That makes sense. the above datumtrans="none" suggestion would keep that
the same.

> I'm not sure what to do about this, whether it's nothing to worry
> about or not.

Worrying is good, as downstream effects of this decision will directly
affect the data. (eg WKT .prj export imported into something else)

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


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


outstanding issue: allow these datumtrans= word aliases?
list => -1
none => 0
default => 1
# bonus:
three_term => a
seven_term => b



Hamish