v.in.ascii summary

[Xin Zhuang]

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 at access.digex.com