[GRASS-dev] [bug #2962] Re: v.digit and region

[Hamish]

Maciek wrote:

> Regarding your recent fix for v.digit:
> 
> > Log Message:
> > restore original region and clear screen on exit.
> 
> I think the real problem about v.digit is that it changes resolution
> during the digitizing session, not that it changes the region extent.
> The latter one, I even like - you can stop digitizing, do some data
> viewing in the given location and restart digitizing from the same
> place.

I agree this is a bad problem. The resolution gets changed because the
zoomed rows and columns are not adjusted to it -- the resolution is
changed to meet the new number of rows,columns so it ends up slightly
off.

"g.region -a" fixes it from the command line:
general/g.region/cmd/main.c

/* res= */
       if (!G_scan_resolution (value, &x, window.proj))
            die(parm.res);
       window.ns_res = x;
       window.ew_res = x;

       if (flag.res_set->answer) {
          window.north =  ceil(window.north/x) * x ;
          window.south = floor(window.south/x) * x ;
          window.east = ceil(window.east/x) * x ;
          window.west = floor(window.west/x) * x ;
       }
[...]
/* nsres= [same for ewres=, tbres=] */
  if (!G_scan_resolution (value, &x, window.proj))
           die(parm.nsres);
  window.ns_res = x;

  if (flag.res_set->answer) {
      window.north = 2 * x * ( (int)(window.north/2/x));
      window.south = 2 * x * ( (int)(window.south/2/x));
  }


I am not sure which is the best approach.

I've never been very happy with int = (int)(float + 0.5); for rounding
either -- i.e. it goes wrong if your float is negative?

guidance?


G_adjust_Cell_head3() is constrained by the fact that rows,cols must end
up as an integer but resolution may be float. If they don't agree, guess
who gets changed? [software generally follows the path of least work]

 
> Do you think it would be hard to prevent v.digit from changing the 
> resolution instead of just reverting original region at quit?

I think it should do both.


> For me, it is huge disadvantage that the background map resolution
> changes as I zoom in and out in v.digit (not mentioning that it might
> lead to crashes in some cases - somehow when the resolution goes too
> fine v.digit can't cope with that). And I'd revert to letting the
> region extents to change as I pan in v.digit, that's cool.
> 
> https://intevation.de/rt/webrt?serial_num=3047
> https://intevation.de/rt/webrt?serial_num=2962
>
> Maybe related:
> https://intevation.de/rt/webrt?serial_num=3164

these are both symptoms of the same bug; reports merged.


> What do you think?


I think that only g.region and d.zoom should be allowed to change the
mapset's region permanently. All other modules should leave the system
in the same state as they found it.

G_put_window()'s help comments support this:
 * <b>Warning.</b> Since this routine actually changes the database region, it
 * should only be called by modules which the user knows will change the region.
 * It is probably fair to say that under GRASS 3.0 only the <i>g.region</i>,
 * and <i>d.zoom</i> modules should call this routine.


Usually a module would use G_set_window() to change the region -- the
difference being that this only persists within the module and the WIND
file is not touched. Apparently (but I am not sure about this) this
doesn't survive the C->Tcl back and forth so v.digit has to use
G_put_window()? It runs both, I'm not sure what happens if you comment
out the G_put_window()s.


in lib/gis/ have a read though the header comments in:
 align_window.c  get_window.c  put_window.c  set_window.c  adj_cellhd.c



Hamish