[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