[GRASS5] strange v.buffer behavior

[Michael Barton]

Thanks Markus. 

This all makes sense now--or at least I understand why v.buffer is not
working as expected. I apparently misunderstood r.to.vect, thinking that if
you did NOT specify a new cat value, it would assign the cat value of the
raster pixels to the vector created. (It DOES do this with areas doesn't
it?). It seems to me at least that this SHOULD be the default, although a
warning should be issued--or even the program should fail--if the number of
different vectors created approaches the number of pixels for lines or
areas.

At least knowing what is happening, we can work around it as you suggest.
Still, it would be nice if we could assign the raster cat to the vector in
many cases.

Michael

______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Markus Neteler <neteler at itc.it>
> Date: Thu, 14 Apr 2005 14:21:26 +0200
> To: Michael Barton <michael.barton at asu.edu>
> Cc: grass5 <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] strange v.buffer behavior
> 
> On Wed, Apr 13, 2005 at 05:04:30PM -0700, Michael Barton wrote:
>> We are having problems with v.buffer in GRASS 6.0 and 6.1. To document this,
>> we tried it on the Spearfish data set. Here is what is happening.
>> 
>> Use v.buffer on the roads.
>> No problem. It behaves as expected.
>> 
>> Convert raster streams to vector (r.thin, r.to.vect)
>> New stream vector displays fine
>> Use v.buffer on converted stream vector.
>> Vector area created with 0 nodes, 0 lines, 0 areas, etc.
>> That is, v.buffer goes through the motions, does NOT generate an error,
>> produces the vector folder and creates all the requisite vector files, but
>> there is NOTHING in them (the coor file is 0kb and the rest are 4 kb‹i.e.,
>> headers only)
>> 
>> Any idea what is going on?
> 
> I have tried: doesn't work
> 
>     r.thin streams out=streams2
>     r.to.vect streams2 out=streams2 f=line
>     v.buffer streams2 out=streams2_buf buf=100
> 
> Because (?):
>     v.category streams2 op=report
>     -> no categories
> 
>     v.db.connect -p streams2
>     Database connection for map <streams2> is not defined in DB file
> 
> I assume that v.buffer only works if categories are present.
> This indicates that something is missing in r.to.vect.
> 
> Analysing the code lines_io.c of r.to.vect shows that there is no
> db_*() support implemented. I darkly remember that this is
> missing due to the problem that you cannot easily assign
> raster values to a line (if you don't want to make each line
> as long as a single pixel).
> 
> Oh, RTFM:
>  Attributes are ignored for feature=line
>  http://grass.itc.it/grass60/manuals/html60_user/r.to.vect.html
> 
> So, once we have an algorithm to decide how to assign attributes
> to lines within r.to.vect, then v.buffer will work (it should
> print an error, though).
> 
> For now v.category will help to assign new categories:
> 
>  v.category streams2 out=streams3 option=add
>  v.buffer streams3 out=streams3_buf buf=100
>  d.vect streams3_buf
> 
> Voila'!
> 
> Markus
>