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 _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
