[GRASS-dev] Re: g.region bugs [was: GRASS 6.3.0 release preparation]

[Maciej Sieczka]

Glynn Clements wrote:
> Maciej Sieczka wrote:
>> Glynn Clements wrote:

>>> Changing the behaviour of -a to align to the new resolution rather
>>> than the original resolution is an incompatible change.

>> Why? It's been already alligning to new res for rasters, see:
>>
>> $ g.region n=5680980 s=5680960 w=602440 e=602480 res=20 -ag

> There is no rast= in the above.

Glynn

"rast=" is not supposed to be there. This is just an initial
region setting. What's really important follows after that.
I'm pasting the message here again with some comments on
what's what (just disregard the previous email if it was
unclear):

# Set the initial region (whatever).

$ g.region n=5680980 s=5680960 w=602440 e=602480 res=20 -ag
n=5680980
s=5680960
w=602440
e=602480
nsres=20
ewres=20
rows=1
cols=2
cells=2

# Create a raster which has resolution matching the current
# region.

$ r.mapcalc 'res20=0'

# Set the region to match the raster, alligning to a *new*
# resolution at the same time:

$ g.region rast=res20 res=1 -ag
n=5680980
s=5680960
w=602440
e=602480
nsres=1
ewres=1
rows=20
cols=40
cells=800

Although the current res is 20 and the raster's res is 20,
the last g.region call above alligns to new resolution "1"
as expected, not to current resolution.

The point is this is different than in case of vectors. With
"g.region vect= res= -a", if your initial resolution is
different from target resolution, region is alligned to
initial resolution. In case of "g.region rast= res= -a" it's
the other way round.

> The -a flag affects the behaviour of vect= and the various resolution
> options (res=, nsres=, ewres=, tbres=), i.e. the only code which tests
> that flag is within the blocks which handle those options.
> 
> The only "global" alignment is the code which adjusts either the
> bounds or the resolution to ensure that the numbers of rows and
> columns are integers, and that is done regardless of whether -a is
> used.
> 
> The way that vectors are handled is strange. First, if either
> dimension is zero, it is expanded to one cell according to the
> existing resolution. Then, if -a is given, the bounds are aligned to
> the existing resolution.
> 
> If you also specify res= (or {ns,ew,tb}res=), the resolution is set;
> this occurs after the bounds have been set by rast=, vect=, [nsewtb]=,
> etc. If -a is given, the bounds are then aligned to the new
> resolution.
> 
> So, when all of vect=, res= and -a are given, the bounds get aligned
> twice; once to the original resolution, once to the new resolution.
> 
> Personally, I think that this is bogus, and I presume that you would
> agree.

Yes.

> But ... it's been this way since at least 5.3[1]. Which means
> that it definitely shouldn't be back ported to 6.2, and it's debatable
> whether it should go into 6.3. I would be more than happy to see it
> changed in 7.x.

I agree some users might realise and rely on this bogus
functionality. On the other hand there must be users who
expect the opposite, "right functionality", not knowing they
have to run "g.region vect= res= -a" twice to obtain a
region as expected, if the initial res is different than
target. Strange nobody ever noticed it.

I'm definitely for fixing this in 7.x. I'm also for doing it
in 6.3.

> [1] Actually, in 5.3, the first alignment of the vector's bounds to
> the existing resolution occurs regardless of whether or not -a is
> given.
> 
> For now, if you want to set the region to a vector's bounds, aligned
> to a specific resolution, you need to run g.region twice; first with
> res=, then with vect= and -a.

I'll document it in 6.2 manual. If it's not going to be
fixed in 6.3, will do teh same.

Maciek