[GRASS-dev] Re: [bug #5454] (grass) projection units incorrectly pluralized

[Hamish]

Paul Kelly via RT wrote:
> I have fixed the "foots" bug now; see
> http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html
> I will commit a temporary solution to the GUI freezing problem
> (changing g.proj so it won't prompt for the datum info unless you ask
> it to be interactive) shortly.

Idea:

It would create a new epsg=code[,n] option:

  g.proj -c location=newLocation epsg=####

It would exit with EXIT_FAILURE if the datum transform parm is ambiguous.

Here's the cunning part:

"epsg=####,n" would pick param 1,2,3,.. from the list.

"epsg=####,0" would print available options to stdout and exit with an
EXIT_SUCCESS return code. If the EPSG code isn't found, it exits with
EXIT_FAILURE. The output is in CSV or a parsable format a GUI could read
& make into a nice GUI popup. Maybe with a header comment line for humans.

In the GUI:
- user selects create new location with EPSG code $EPSG.

- gui runs "catch `g.proj epsg=$EPSG` > /dev/null"

- If exit code is 0, gui creates new location with:
    "g.proj -c location=$LOCATION epsg=$EPSG"

- If exit code is 1, gui runs:
    "g.proj epsg=$EPSG,0"  then parses the output and creates a new
  GUI popup with radiobutton options generated from that. (see d.menu)
  (If it fails again, EPSG code is bad)

  Once a parm is selected and [Create] is clicked, the popup runs
    "g.proj -c location=$LOCATION epsg=$EPSG,$N"


IMO this would be many many times better than forcing a value (you
wouldn't even know better transform parms exist), and isn't a huge
amount to code.



Hamish