[GRASS-dev] Re: [GRASS GIS] #295: region corrupted

[GRASS GIS]

#295: region corrupted
-----------------------+----------------------------------------------------
  Reporter:  msieczka  |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect    |      Status:  new                      
  Priority:  critical  |   Milestone:  6.4.0                    
 Component:  wxGUI     |     Version:  svn-develbranch6         
Resolution:            |    Keywords:                           
  Platform:  All       |         Cpu:  All                      
-----------------------+----------------------------------------------------
Comment (by hamish):

 All that has happened here is that 'g.region -a' has been run by the GUI,
 which "snaps to the grid".

 n-s is the same in both of your cases, but in the second case n,s is
 exactly divisible by the nsres. (give or take 2e-6 error introduced by
 g.region outputting to terminal using %f; internally the double prec FP
 variables will equate)


 By default if there is a conflict g.region respects the region bounds over
 the resolution (I would guess this reduces >90deg LL problems and is the
 less risky solution in the original GRASS military context!). With the -a
 flag the resolution ''grid'' is respected over the bounds and the bounds
 are "snapped" to the resolution grid with origin 0,0.

 this causes an interesting problem,
 {{{
 G> g.region n=100525 s=100475 w=500825 e=500875 res=50 -g
 n=100525
 s=100475
 w=500825
 e=500875
 nsres=50
 ewres=50
 rows=1
 cols=1
 cells=1

 G> r.mapcalc one=1

 G> g.region res=50 -a -g
 n=100550
 s=100450
 w=500800
 e=500900
 nsres=50
 ewres=50
 rows=2
 cols=2
 cells=4

 G> d.rast one
 G> d.grid 25
 }}}

 note that g.region rounds outwards, and that resampling shifts the cell to
 the N and W by 1/2 a cell. In these cases my work around solution has been
 to half the resolution,
 {{{ g.region res=25 -ag }}}
 then no resampling shift occurs by careless user mistake.


 You ran:
 {{{
 3. In wxGUI: "Set computational region from display"
 }}}

 so you can expect the region to change.


 If there is a problem it is that the
 {{{ g.region n=100525 s=100475 w=500825 e=500875 res=50 -g }}}
 case may? be resamped by the GUI into the attached "after -a" image.
 I haven't checked that. But if you know about the resampling issue (I
 believe there's a paragraph about it in the g.region help page), this
 problem is easily worked around, and much less painful than having -a as
 the default. (IMO to switch that would be a horrible mistake)

 fwiw, screenshots created with xmons+d.out.file, not from the GUI.


 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/295#comment:5>
GRASS GIS <http://grass.osgeo.org>