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

[Maciej Sieczka]

Martin Landa wrote:
> Maciej Sieczka wrote:

>> Also, the bug g.region [2] is very serious. Any chances
>> these 2 bugs could be fixed before relasing 6.3? It would be
>> much better not to release with *known* bugs which might
>> corrupt users data.
>>
>> [2]http://wald.intevation.org/tracker/?func=detail&atid=204&aid=489&group_id=21

> should be fixed in CVS...

Martin

Yes it is! Cool.

Yet, there is some more evil lurking in g.region - when the
initial resolution is different than resolution requested in
a "g.region vect=line res=1 -a" call, the region is set
wrong (present in both CVS GRASS 6.2 and 6.3). Eg.:

1. Set the region to something like:

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

2. Create a vector line within the region:

$ echo "L  2 1
602473.66691719 5680962.45268225
602448.70284465 5680961.09147704
1 1" | v.in.ascii -n form=standard out=line

3. Set the region to match the extent of vector line and
force resolution "1":

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

The above g.region result is wrong. It should be:

n=5680963
s=5680961
w=602448
e=602474
nsres=1
ewres=1
rows=2
cols=26

This happens when the initial region (set in point #1) is
different than target resolution (requested in #3).

Would you mind looking into this bug too?

Best,
Maciek