I had asked our grass group for a help on
v.in.ascii. I run the following:
v.in.ascii
v.support
v.to.rast
r.support.
But I got a layer with one category only.
I was told I had to use v.digit if I didn't
had the coressponding dig_att, which is true.
However, v.digit is kind of tedious. SO I created
a dig_att file. I still got the same as
what I got without dig_att. So I dived into
v.in.ascii (in src/mapdev/v.in.ascii) and found
the following, which I think it's a bug:
code from v.a_b_dig.c<<<
char file1[300], file2[300];
G__make_mapset_element( "dig_att");
if (0 ==access (file1, 0))
{
G__file_name (file1, "dig_att", old->answer, mapset);
G__file_name (file2, "dig_att", new->answer, G_mapset());
cp_file (file1, file2);
}
modified code<<<
char file1[300], file2[300];
G__make_mapset_element( "dig_att");
G__file_name (file1, "dig_att", old->answer, mapset);
G__file_name (file2, "dig_att", new->answer, G_mapset());
if (0 ==access (file1, 0))
cp_file (file1, file2);
end of code<<<
Before I report to grass as a bug, I would apprecite if someone
give a double check. You can apply v.out.ascii to QUADS in spearfish.
Let's call it "quads.ascii". v.out.ascii does create quads.ascii
in dig_att. Now we have bot dig_ascii and dig_att. Run the modified
v.in.ascii and give the vect a name "lucky". You'll see "lucky"
in dig_att right after the running, and it's exactly the same as
quads.ascii. You won't see one in dig_att if using the existing
v.in.ascii to repeat the process.
Go back and look at the code listed above, I think you would
agree on what I modified. It's so costly. It took me a few
hours to come to this point. I'd like to share with everyone
in the grass group.
Look forward to feedback,
--Xin Zhuang
zhuang@access.digex.com