[GRASS-dev] Re: [GRASS GIS] #37: r.in.xyz increase region based on input data

[Maris Nartiss]

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 <trac at osgeo.org>:
>
>  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.