[GRASS-dev] g.proj to create a new location
hamish_nospam at yahoo.com
Thu Feb 15 03:35:26 EST 2007
> 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.
> 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?
More information about the grass-dev