Newsgroups: info.grass.programmer
Path: zorro.cecer.army.mil!shapiro
From: shapiro@zorro.cecer.army.mil (Michael Shapiro)
Subject: Re: v.in.ascii summary
Message-ID: <C801Do.EHJ@news.cecer.army.mil>
Sender: news@news.cecer.army.mil (Net.Noise owner)
Organization: US Army Corps of Engineers Construction Engineering Research Labs
References: <199305211600.AA01518@access.digex.net>
Date: Wed, 2 Jun 1993 14:53:48 GMT
Lines: 62
In <199305211600.AA01518@access.digex.net> zhuang@access.digex.net (Xin Zhuang) writes:
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.
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.
Yes, this is a bug. The fix looks right, too. Please report it.
--
Michael Shapiro shapiro@zorro.cecer.army.mil
U.S. Army CERL (217) 373-7277
P.O. Box 9005
Champaign, Ill. 61826-9005