[GRASS-dev] v.what and spatial index

[Glynn Clements]

Moritz Lennert wrote:

> >> How would this change from the first approach (if v.what could easily be 
> >> made to accept multiple coordinates) ? This would again mean 'blindly' 
> >> collecting points before seeing the results, or having to call v.what 
> >> multiple times.
> > 
> > v.what would read one coordinate pair, perform the lookup, write out
> > the result(s), repeat until EOF.
> > 
> > gis.m would start one v.what process; each time you click the mouse
> > button, it would send the coordinates to the v.what process, read the
> > result, then display it. It would need to restart v.what if the set of
> > maps changed, but could use a single process to look up multiple
> > points.
> 
> Here's my attempt at applying what you suggest. It's not very 
> complicated, and seems to work fine here, but I'd appreciate if someone 
> could check that I didn't do anything wrong before committing.

One issue which won't show up when running it directly from the shell,
but will if you run it via pipes: you need to explicitly set stdin and
stdout to line-buffered operation with e.g.:

	setvbuf(stdin,  NULL, _IOLBF, 0);
	setvbuf(stdout, NULL, _IOLBF, 0);

> Now we will have to change the query function in the gis manager (from 
> line 1474 of gui/tcltk/gis.m/mapcanvas.tcl) to use v.what with the -s 
> flag and to provide continuous flow of coordinates and an EOF at the 
> end. Michael, can you do this ? Or could someone tell me in rough lines 
> how this can be done ?

Ah. Tcl's "open" function doesn't directly support using pipes for
both stdin and stdout; you can choose read (stdout is a pipe, stdin is
inherited) or write (stdin is a pipe, stdout is inherited), but not
both.

You will need to create a named pipe (with mkfifo) then explicitly
redirect one of the ends to it, e.g.

	set fifo $tmpdir/$tmpname
	exec mkfifo $fifo
	set rfh [open "|v.what map=$maplist <$fifo" r]
	fconfigure $rfh -buffering line
	set wfh [open $fifo w]
	fconfigure $wfh -buffering line

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