[GRASS-dev] v.what and spatial index

Moritz Lennert mlennert at club.worldonline.be
Wed Sep 13 10:32:59 EDT 2006


Michael Barton wrote:
> Moritz,
> 
> I'm tied up all day. I'm not exactly sure how you want to change the 
> behavior of v.what in gism. That is, I don't understand about a stream 
> of coordinates. Could you explain it a bit better. Sorry if I'm dense.

The problem: v.what builds the spatial index everytime it is called. For 
large files this takes a while making the use of v.what on several 
points in a row very slow. The query tool of gis.m calls v.what for 
every query click.

The solution: Allow v.what to accept more than one pair of coordinates 
by listening on stdin until it reveives an EOF call. The query tool in 
gis.m opens a connection to v.what in the way described by Glynn below, 
feeds in the coordinates everytime the user clicks on the map, displays 
the relevant information and continues to wait for the next click unless 
it receives some sort of EOF (example: user choses different tool in map 
display window - or a right click, whatever seems the most convenient). 
That way a user can display a map, click at different points of the map 
and immediately receive the information, without having to wait for the 
spatial index to be built because of separate v.what calls.

Does that make sense ?

If it is not too difficult to implement in gis.m it would be great to 
have it. Otherwise, it would have to wait for the next gui...

Moritz


> 
> Michael
> On Sep 13, 2006, at 6:32 AM, Moritz Lennert wrote:
> 
>> Glynn Clements wrote:
>>> 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);
>>
>> I assume this can be done anywhere as long as its before the call to 
>> stdin ?
>>
>>>> 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
>>
>> Ok, I understand the principle of this, but don't know how and where 
>> to apply it in mapcanvas.tcl. Don't have the time to dig into it right 
>> now. Michael ?
>>
>> Another question is whether it is worth doing all this (don't know how 
>> much work it is to apply Glynn's solution) if we are going to change 
>> GUI in a foreseeable future...
>>
>> Thanks, Glynn, for your help.
>>
>> Moritz
>>
> 
> ____________________
> C. Michael Barton, Professor of Anthropology
> School of Human Evolution and Social Change
> PO Box 872402
> Arizona State University
> Tempe, AZ  85287-2402
> USA
> 
> Phone: 480-965-6262
> Fax: 480-965-7671
> www: <www.public.asu.edu/~cmbarton>
> 
> 




More information about the grass-dev mailing list