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

[Michael Barton]

Hamish and Paul,

I've followed this closely and tried to save relevant emails, but it's been
a bit complicated. I've been trying to put aside TclTk and work on the
wx.Python GUI, but this seems important to do in the existing TclTk
interface. 

Any chance you could briefly summarize how g.proj now works (or will work)
with these changes so that I can try to update the TclTk interface for this?

Michael


On 2/7/07 9:28 PM, "Hamish" <hamish_nospam at yahoo.com> wrote:

> Paul Kelly wrote:
>> 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.
> 
> Hmm. Is the default based on logic or is it just picked as the first
> listed in the file, or something like that? If it is random we can
> keep the code simpler. Keeping the first entry as default means that the
> datumtrans= option (and thus GUI) can be skipped in the case there is
> only one option.
> 
> H:
>>> It would be nice. I guess another thing missing is region setting
>>> code to replace E_edit_cellhd(). More g.proj -c options?
> P:
>> 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.
> 
> Yes, that's better.
> 
> The new location would have to be created and switched into before
> running g.region in PERMANENT, and then the GUI wizard would take you
> on to creating a user mapset before switching into that and launching
> a new GRASS session.
> 
> 
>> 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.
> 
> Well, we can get the epsg= and datumtrans= options working, and then
> worry about those issues- maybe we will learn some along the way.
> It may be that g.proj is not the best place to put a top-down chooser
> and we'd need a new module "g.newlocation" or something?
> 
> 
> Hamish
> 
> 

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton