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

Glynn Clements glynn at gclements.plus.com
Wed Jun 21 13:34:28 EDT 2006


Hamish wrote:

> 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?

	int = (int) floor(float + 0.5);

> 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.

A program which needs to run other modules with a different region
should use either GRASS_REGION or WIND_OVERRIDE.

> 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.

Definitely.

> 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.

If WIND_OVERRIDE is set, G_put_window() will modify the named region
specified by that variable rather than the WIND file.

For v.digit, using GRASS_REGION is probably more appropriate, although
slightly more work (AFAIK, you have to construct the string yourself).

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list