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

[Hamish]

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