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

[Maciej Sieczka]

Glynn Clements wrote:
> Maciej Sieczka wrote:

>> So, we are back to were it all started. More findings and
>> details follow.
>>
>> Correction to original report - the bug *does* crop out in
>> GRASS 6.2.3 CVS too. However, differently. Please see:
>>
>> The vector line is as follows:
>>
>> $ echo "L 2 1
>> 602473.66691719 5680962.45268225
>> 602448.70284465 5680961.09147704
>> 1 1" | v.in.ascii -n form=standard out=line
>>
>>
>>
>>  IN GRASS 6.2.3 CVS:
>>
>> $ g.region n=5680980 s=5680960 w=602440 e=602480 res=20 -a
>>
>> $ g.region vect=line res=1 -ag
>> n=5680980
>> s=5680960
>> w=602440
>> e=602480
>> nsres=1
>> ewres=1
>> rows=20
>> cols=40
>>
>> Wrong. But let's try again:
>>
>> $ g.region vect=line res=1 -ag
>> n=5680963
>> s=5680961
>> w=602448
>> e=602474
>> nsres=1
>> ewres=1
>> rows=2
>> cols=26
>>
>> Correct this time! Strange.

> The -a flag causes the region to be aligned to the existing
> resolution; the res= etc options aren't processed until later.

>>  IN GRASS 6.3 CVS:

<snip>

> In 6.3-CVS, the -a flag aligns the vector to itself (!), rather than
> to the original region.
>
> AFAICT, the error was introduced when the vect= option was extended to
> allow multiple maps. Previously, temp_window was used to hold the
> original region so that the new region (in window) could be aligned to
> it.
> 
> The changed version uses temp_window to hold the region for the
> current vector map (the bounds from the map but with the original
> resolution) while window holds the cumulative region. The original
> region is no longer stored anywhere, so alignment is not possible. The
> change should have added a third variable rather than re-using
> temp_window.
> 
> I've fixed this in CVS, where "fixed" means "behaves as in 6.2". 

I confirm g.region behaves the same in 6.2 and 6.3 now. Thanks.

> 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
n=5680980
s=5680960
w=602440
e=602480
nsres=20
ewres=20
rows=1
cols=2
cells=2

$ r.mapcalc 'res20=0'

$ 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 g.region call above alligns to new resolution, not the
current.

Maciek