[GRASS-dev] g.rp

[Paul Kelly]

On Wed, 7 Feb 2007, Hamish wrote:

>> 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...
>
> As long as there is some hinting, we can make the rest happen in code.
> It shouldn't be too hard to reindex the list. (he says not having looked
> at the code :)

No not hard at all. In fact I have just changed it. The original thinking 
was that since the "default" parameters were unlikely to be optimum it 
made sense to put them at the end of the list so the user didn't consider 
them a good default choice. But it isn't that important especially since 
we've added the more informative comment about being unlikely to be 
optimum.

>>> 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?
>
> Well my idea was put the default first and when combined with
> ->answer="1" it happens automatically. I'd prefer to use the parser to
> pick the default answer rather than it happen somewhere inside the black
> box, but it guess it doesn't have to.

Yes that is very neat, I agree (and have changed the order of the list as 
mentioned above).

> My main goal was that the default parm should be the default option,
> regardless of order. The easiest way to have that happen is to call it
> "1" and have parm->answer="1" in the option's parser def'n, after making
> sure the default parm comes first.
>
>> I think a solution acceptable to everyone is gradually forming over
>> time. This is what I hoped would happen!
>
> It would be nice. I guess another thing missing is region setting
> code to replace E_edit_cellhd(). More g.proj -c options?
> region=n,s,e,w
> nsres=
> ewres=

I think I would prefer Helena's solution of adding a flag to g.region to 
allow it to set the default region. The GUI could then call g.region on 
the new location (after updating .grassrc) following its creation with 
g.proj.

> Also we need to have a replacement GUI top-down location creation method
> (pick type, then projection, then datum), vs the bottom-up EPSG code way.
>
> Maybe a g.listproj module that would give existing type, SP, proj lists
> from lib fns in a CSV or other GUI parsable format?
> e.g. this would call a non-paged version of lib/gis/get_projname.c:
> g.listproj type=projections
> or
> g.listproj type=state_plane
> ??

If the way the new datumtrans flag works for g.proj is a success it could 
probably be done in a very similar way, using library functions in 
lib/proj/ellipse.c and lib/proj/datum.c to read the system ellipsoid and 
datum tables. Maybe - I haven't really thought it through. Might get a bit 
out of hand.

Paul