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

[Hamish]

> Hamish wrote:
> >> Yes. With datumtrans=-1 the location will get created straight away
> >> if there is only one parameter set to choose from (unless you use
> >> the force flag). The GUI could watch the output of g.proj and if it
> >> specifed the list then go through it for the second pass.
> >
> > ? The -1 "list" option should only list and exit. Not sometimes
> > work, sometimes not. My hope was that the GUI could see there were
> > no options and skip the param picker dialoge and move right on to
> > the -c creation step. ie datumtrans=-1 should ignore -c, otherwise
> > it is trying to be two orthogonal modes at the same time.

Paul:
> Well the way it is is consistent with how it worked before. If the
> datum  information was complete, g.proj did what you told it, if not
> it prompted  for more info. Now if you use the -i flag you can still
> get this old  behaviour, or if you specify datumtrans=xxx
> 
> I can see logic in datumtrans=-1 always listing even if there is just
> one option, but I still think the current way is better as it is most
> consistent with pre-existing behaviour... :/ If you want it to always
> list anyway you can use the -t "force transformation selection" flag?
> 
> Not sure what's best really


As we didn't have datumtrans= before, we really would just be preserving
the awkward style of how it functioned, not exact usage. Adding the new
options is an oportunity to smooth out any anomalies in the process...
?

I'm still trying to come to grips with how the result of -t differs
from datumtrans=0 ("none"). ie why datumtrans=0 doesn't imply -t.
That also touches on why datumtr=0 should be the default and not =1?
Sorry if that makes no sense. Is there a case where EPSG defines
datum parms and datumtransform.table defines more?

example?


Hamish