v.to.rast:error G_set_window()

GRASS GRASS user
1

Dear grass developpers:

When running v.to.rast using grass5.0beta, I've found
that if the resulting raster needs more than
one single processing pass, the result is wrong.
The program outputs a warning:

WARNING: Calling G_set_window() in the middle of
writing map vgeugoode

and then the result is either misslocated or blank.

I reproduce an example:

alobo@silvestre:~/grass/gr_P8/user1/cell > g.region -p
projection: 0 (x,y)
zone: 0
north: 5325500
south: 3285500
east: 4360500
west: -255500
nsres: 1000
ewres: 1000
rows: 2040
cols: 4616

alobo@silvestre:~/grass/gr_P8/user1/cell > v.to.rast in=vgeugoode.v
out=vgeugoode
Loading vector information ... 0 mins 00 secs
Sorting areas by size ... 4159 areas 0 mins 01 sec
Pass #1 (of 4)
  Processing areas ... 4159 areas 0 mins 04 secs
  Processing lines ... 0 lines 0 mins 00 secs
  Processing sites ... 0 sites 0 mins 00 secs
  Writing raster map ...WARNING: Calling G_set_window() in the middle of
writing map vgeugoode
                        0 mins 09 secs
Pass #2 (of 4)
  Processing areas ... 4159 areas 0 mins 03 secs
  Writing raster map ...WARNING: Calling G_set_window() in the middle of
writing map vgeugoode
                        0 mins 08 secs
Pass #3 (of 4)
  Processing areas ... 4159 areas 0 mins 03 secs
  Writing raster map ...WARNING: Calling G_set_window() in the middle of
writing map vgeugoode
                        0 mins 09 secs
Pass #4 (of 4)
  Processing areas ... 4159 areas 0 mins 02 secs
  Writing raster map ... 0 mins 03 secs
Creating support files for raster map ... 0 mins 15 secs

Raster map <vgeugoode> done.
Total processing time: 0 mins 57 secs

If I use an smaller region, the result is correct:

alobo@silvestre:~/grass/gr_P8/user1/cell > g.region -p
projection: 0 (x,y)
zone: 0
north: 5325500
south: 3285500
east: 4360500
west: -255500
nsres: 8000
ewres: 8000
rows: 255
cols: 577

alobo@silvestre:~/grass/gr_P8/user1/cell > v.to.rast in=vgeugoode.v out=vgeugoode
Loading vector information ... 0 mins 00 secs
Sorting areas by size ... 4159 areas 0 mins 01 sec
Processing areas ... 4159 areas 0 mins 03 secs
Processing lines ... 0 lines 0 mins 00 secs
Processing sites ... 0 sites 0 mins 00 secs
Writing raster map ... 0 mins 00 secs
Creating support files for raster map ... 0 mins 13 secs

Raster map <vgeugoode> done.
Total processing time: 0 mins 17 secs

Agus

****NOTE NEW PHONE NUMBER*****
Dr. Agustin Lobo
Instituto de Ciencias de la Tierra (CSIC)
Lluis Sole Sabaris s/n
08028 Barcelona SPAIN
tel 34 93409 5410
fax 34 93411 0012
alobo@ija.csic.es
http://pangea.ija.csic.es/alobo

2

Agustin Lobo wrote:

When running v.to.rast using grass5.0beta, I've found
that if the resulting raster needs more than
one single processing pass, the result is wrong.

[...]

I reproduce an example:

[ First attempt ...]

rows: 2040
cols: 4616

[Second attempt with a smaller region ...]

rows: 255
cols: 577

You will notice that in the first run, you have 2040 rows, and
that the job is done with 4 passes. The second time, once pass is
enough.

There is an undocumented parameter in v.to.rast : "rows=512"
gives the number of rows keeped in memory (512 by default). This
is the reason why your first run uses 4 passes. 4 x 512 -> 2048.

Try "v.to.rast in=vgeugoode.v out=vgeugoode rows=2040" with the
first region. It should work, without any change in the sources.

--
Michel Wurtz ENGEES - CEREG
                1, quai Koch - BP 1039, F-67070 STRASBOURG cedex
                Tel: +33 03.88.24.82.45 Fax: +33 03.88.37.04.97

3

On Thu, 8 Jul 1999, Michel Wurtz - ENGEES/CEREG wrote:

Agustin Lobo wrote:
> When running v.to.rast using grass5.0beta, I've found
> that if the resulting raster needs more than
> one single processing pass, the result is wrong.
[...]

You will notice that in the first run, you have 2040 rows, and
that the job is done with 4 passes. The second time, once pass is
enough.

There is an undocumented parameter in v.to.rast : "rows=512"
gives the number of rows keeped in memory (512 by default). This
is the reason why your first run uses 4 passes. 4 x 512 -> 2048.

Try "v.to.rast in=vgeugoode.v out=vgeugoode rows=2040" with the
first region. It should work, without any change in the sources.

Thanks, it works. It seems that there is a bug that affects only
if more than 1 page is needed.

Agus

4

At 17:09 12.7.1999 +0200, you wrote:

On Thu, 8 Jul 1999, Michel Wurtz - ENGEES/CEREG wrote:

Agustin Lobo wrote:
> When running v.to.rast using grass5.0beta, I've found
> that if the resulting raster needs more than
> one single processing pass, the result is wrong.
[...]

You will notice that in the first run, you have 2040 rows, and
that the job is done with 4 passes. The second time, once pass is
enough.

There is an undocumented parameter in v.to.rast : "rows=512"
gives the number of rows keeped in memory (512 by default). This
is the reason why your first run uses 4 passes. 4 x 512 -> 2048.

Try "v.to.rast in=vgeugoode.v out=vgeugoode rows=2040" with the
first region. It should work, without any change in the sources.

Thanks, it works. It seems that there is a bug that affects only
if more than 1 page is needed.

Hello all,

This bug affects several commands including r.in.poly,r.digit,r.flow,..

The bug is in ~src/libes/gis/set_window.c between lines 97-119.
My quick fix was to remove these lines and re-compile gis lib and also
all affected commands. Of course, it would be better to fix it in a more
convenient way, however I have no time to figure out what is wrong there...

Jaro