Moving discussion into more general plane. Is there some document where general GRASS module policies are described? If such document does not exist, probably we should create one (programmers manual? trac wiki?). Such document could contain short must/should/suggested things to unify/make similar various module behavior. It could be used by developers while developing new modules or cleaning/fixing existing ones. Some candidates (just examples): "Scripts should not touch WIND file but use $WIND_OVERRIDE instead"; "r.in.* modules should import data in their native resolution (if possible) ignoring current region settings. They may provide region controlled import mode activated by -? flag" etc.
Just trying to make GRASS better, Maris. 2008/2/6, GRASS GIS <[EMAIL PROTECTED]>: > > r.in.xyz shouldn't change the current region. > > What it probably *should* do is to create a map whose size is based upon > the input data, rather than using the current region. IOW, the way that > other r.in.* commands work; unlike most r.* commands, the output from > r.in.* commands isn't normally based upon the current region. > > This would require two passes, which won't work with input=- if stdin is a > pipe. But then the same is true of a script which runs r.in.xyz -s, > g.region, r.in.xyz. > > A script approach should definitely use either $WIND_OVERRIDE or > $GRASS_REGION rather than modifying WIND. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev