[GRASS5] GRASS 6.0.1 release schedule
Hamish
hamish_nospam at yahoo.com
Sun Jul 3 22:31:37 EDT 2005
> > I wonder if there was a good reason to put in the full path, perhaps
> > it is more simple to use ("$GISBASE/etc/nad/%s",nad_file) instead
> > of ("%s/%s",nad_dir,nad_file) ?
> >
> > Makes the output non-useful for use outside of GRASS but it
> > certainly makes it easier to read and the output portable across
> > systems (e.g. bug reports), especially when your $GISBASE is
> > something long like:
> > /home/user/src/grass/grass61-cvs/dist.i686-pc-linux-gnu.
>
> Sounds like a promising idea. Perhaps it is unlikely that the output
> of g.proj would be used outside a GRASS session anyway.
And if it was, $GISBASE would still need to be set already anyway.
> The only thing I would worry about is will the GISBASE environment
> variable always be expanded
I see. The following would then fail:
IN_PROJ="+proj=longlat +towgs84=0.000,0.000,0.000"
OUT_PROJ="`g.proj -jf`"
echo "166 -45" | cs2cs -f %.7f $IN_PROJ +to $OUT_PROJ
as $GISBASE in $OUT_PROJ wouldn't be expanded. The above example would
have to look like this:
IN_PROJ="+proj=longlat +towgs84=0.000,0.000,0.000"
OUT_PROJ_RAW="`g.proj -jf`"
OUT_PROJ="`eval echo $OUT_PROJ_RAW`"
echo "166 -45" | cs2cs -f %.7f $IN_PROJ +to $OUT_PROJ
which isn't nearly as clean.
(maybe there is a more concise way of expanding it?)
So the choice is a messy non-portable string or forcing users to jump
through non-obvious hoops in their scripts. Comments please, but I guess
best practices says we should make the string messy and the script clean?
> or might there be quoting arrangments (currently in use by users)
> where it doesn't expand.
Anything using a +nadgrids from g.proj will currently fail anyway, so no
more broken than it was before. In fact we'd be in a better position
because it wouldn't fail silently anymore- PROJ.4 prior to current CVS
would (if the grid file wasn't found) make the first coordinate pair
"* *" and after that return valid numbers which were missing the datum
transform. No data is better than bad data.
So.. I guess we leave the status quo?
Hamish
More information about the grass-dev
mailing list