r.what: shouldn't use static buffers for the inputs

[1gray]

It seems that I'm a lucky one to face all these ``static buffer'' issues.

$ r.what \
      input=2006-08-{0{1,2,3,4,5,6,7,8,9},{1,2}{0,1,2,3,4,5,6,7,8,9},3{0,1}}.[...].{{1,2,3,4,5,6,7,8,9},1{0,1,2,3,4,5,6,7,8,9},20} \
      east_north=[...]
r.what: can only do up to 150 cell files, sorry
$ 

Surely I can raise NFILES in raster/r.what/main.c, but wouldn't it be better to replace all the mess in r.what with a pure dynamic buffer-based solution? (Hopefully I could make a patch.)

I've tested the command above with GRASS 6.2.3-debian-1, but I can see the relevant code in a recent SVN trunk as well.

[1gray]

On the other hand, (much of) the r.what functionality could easily be achieved by using v.what.rast together with v.db.select.

Shouldn't therefore r.rast be replaced by a (supposedly simpler) Shell script?

[glynn]

Replying to 1gray:

Shouldn't therefore r.rast be replaced by a (supposedly simpler) Shell script?

No. For a start, v.what.rast only accepts a single raster map. Also, r.what shouldn't depend upon the vector and database functionality (most raster modules should still work if e.g. you can't GDAL to work).

[neteler]

The limit of currently #define NFILES 400 continues to exist.

[neteler]

See also #2564

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after 7.0.3 milestone closed

[martinl]

Milestone renamed

[neteler]

Ticket retargeted after milestone closed

[martinl]

All enhancement tickets should be assigned to 7.6 milestone.

[martinl]

Ticket retargeted after milestone closed

[martinl]

Ticket retargeted after milestone closed