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