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

[Paul Kelly]

On Tue, 6 Feb 2007, Hamish wrote:

> Hamish wrote:
>>> 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.
>
> Michael:
>> I haven't thought through all the implications, but on the face of it this
>> sounds like a reasonable solution. If implemented, hopefully it would be
>> able to run without lockup (succeed or fail with warning) with the current
>> TclTk scripts until the GUI could be re-written for this.
>
> The whole idea is to made g.proj fully non-interactive and leave that to the
> GUI.
>
> I guess instead of epsg=####[,n] the [,n] part should go in a datumtrans=
> option as it could apply to georef=,wkt=,proj4= as well.
>
> This would print a GUI parsable list of options: (or error if bad epsg code)
> g.proj epsg=#### datumtrans=0
> or
> g.proj epsg=#### datumtrans=list

Yes it's starting to make more sense now when you put it like that. 
Although as Glynn said maybe the GUI should be reading the datumtransform 
tables itself, although again it has no way of telling from the EPSG code 
what the associated datum is. Even I am not sure how it does it. Some 
magic inside the OGR library I think.

I still worry a little that it depends too much on the existing structure 
of support for datum transform parameters within GRASS. Michael made an 
interesting point that perhaps the EPSG database contains some sets of 
paramters. But even if it does, we can't guarantee that they're correct or 
complete or best. The whole point of the EPSG database is (from it's 
name) petroleum survey, I presume. Which means it would be more likely to 
include datum paramters useful for oilfield areas etc.? I don't know if it 
does contain paramters, nor how to extract them. I would guess though that 
it doesn't use PROJ.4 syntax, nor contain New Zealand Map Grid tables or 
Canadian NTv2 tables etc. the way GRASS does.

I think a solution acceptable to everyone is gradually forming over time. 
This is what I hoped would happen!

> if there is only one item on the list the GUI would automatically run
> with that, "datumtrans=1" would be the default answer:
>  g.proj -c loc=newLoc epsg=####

Actually the function GPJ_get_default_datum_params_by_name() in 
lib/proj/datum.c returns a "default", which for various reasons is 
actually the last in the list...

>
> If multiple options the GUI would create a dialog from the list,
> then create the new location with:
> g.proj -c loc=newLoc epsg=#### datumtrans=2
> or
> g.proj -c loc=newLoc epsg=#### datumtrans=conus   # ???
>
>
> Not sure if it should take text "list,conus,etc".
> Probably that is unneeded pain. Aliasing "list" to "0" would be nice

Yes I see where you're coming from, I think. If the first item in the list 
was the default anyway this would work out nicely. Maybe omitting the 
datumtrans option could mean use the default instead of datumtrans=1?


Paul

> but wouldn't get past parser checks for TYPE_INTEGER and
> parm->options="0-100";.
>
>
>
> Hamish
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>